• 0
jli853

OS overhead of the JTAG-USB bits transfer

Question

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()

Share this post


Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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?

 

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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.

Edited by xc6lx45

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now