OS overhead of the JTAG-USB bits transfer

[jli853]

Does anyone know the OS/SW overhead when shifting JTAG bit chains from controller to device?

For example, how long it takes to execute this function from the Adept SDK library?

DjtgPutTmsTdiBits()

[jpeyron]

Hi @jli853,

I reached out to one of our design engineers about this forum thread. They responded that

"Unless you do a non-blocking (overlapped) transfer the time it takes to execute the function will include not only the time to transfer the data over USB but also to shift it onto the JTAG scan chain. When the function returns all data has been transferred to the target JTAG device. How long that takes is going to very with the TCK frequency, as well as the PC side hardware and operating system. I don’t have any measured data to provide."

thank you,

Jon

[jli853]

Thanks @jpeyron for your reply!

So did you mean that it is possible to improve the time by doing a non-blocking transfer?

I am not familiar with the overlapped option in the function, could you please explain it a bit more?

 

[jpeyron]

Hi @jli853,

I reached out to the  design engineer and they responded that doing a non-blocking transfer isn’t going to reduce the amount of time that it takes for a transfer to complete, and in fact, will increase the overall CPU time used to perform the transfer because now the application has to poll the completion status. All a non-blocking transfer will do is allow you to free up your application thread so that it can do something else, such as a refresh a GUI. They said “overlapped” previously because the function parameter that tells the Runtime to perform a non-blocking transfer is named fOverlap (at least internally). You can’t do real overlapped data transfers (start one, then start another before the first finishes, etc).

thank you,

Jon

[xc6lx45]

Hi,

if speed is more important than convenience, you can have a look at my JTAG code here. It works with some of the FTDI-based JTAG adapters, those that follow FTDI's recommended pinout internally.

https://github.com/mnentwig/busbridge3/tree/df2f65a8fede13cb5874815da8cf22e81d72123c

For example, the final read bit with TMS high is done in line 219 here: https://github.com/mnentwig/busbridge3/blob/df2f65a8fede13cb5874815da8cf22e81d72123c/busBridge3/bb3_lvl3_jtag.cs

It collects all events and sends them in block via USB. This should give the fastest possible response time. But the "read" functions cannot immediately return data (since the command sequence is run on hardware only later), they provide a "handle" to return data instead, after the block has been sent to hardware.

[jli853]

Quote

Thanks @jpeyron and @xc6lx45 for all the comments above!

Appreciate your insightful information.