I’m using a Saxo-L from fpga4fun. I want to get an idea of the JTAG speed I can get with this thing. The board has an integrated JTAG over USB connection that works with OpenOCD.
The experiment:
First I use the “load_binary” command in RAM (loads a 64KB file in 6.3s).
Now I tried to program the file into flash with “dcc_downloads” disabled. It takes 13s for a 100KB file.
Now I enable “dcc_downloads”. Flashing takes 8.5s, which is faster than RAM!?!
The questions:
Is there overhead with the load_binary command? Why is Flash programming sometimes faster than RAM access?
How can I verify that the flash programming succeeded? I found that I can use the “dump_binary” command to save the flash into a file and then use a file binary compare on the PC. But is there an easier way?
When “dcc_downloads” is enabled, OpenOCD reports errors like “Warning: value captured during scan didn’t pass the requested check: captured: 0x09 check_value: 0x01 check_mask: 0x0f”. Is that a known bug or possibly a problem with Saxo JTAG stack?
load_binary is the most direct way of transfering a larger block of data to a target’s RAM
Currently there isn’t a verify option. I always wanted to add one, but I never missed it enough to actually write code for it.
These warnings indicate problems with the JTAG communication. I have no idea what JTAG interface fpga4fun uses on that board. The only USB-JTAG chip supported by the OpenOCD is FTDI’s FT2232, but that board doesn’t seem to have one, according to the pictures. Could you please paste your .cfg file?
I don’t know that interface (fx2jtag), and I don’t know who wrote the code for it. Did that version of the OpenOCD come with the board, and did it come with source code?
The failing check you’re getting a warning about is used to verify that the fixed value of b0001 got captured on every JTAG IR scan. The LPC21xx behaves fine in that regard, and enabling DCC downloads shouldn’t cause the problems you’re seeing.
I’m generally reluctant when it comes to including support for proprietary JTAG interfaces like yours.
I already declined to include one for a proprietary commercial product, and currently I’m not sure if I’m going to include support for this.
I’m already unhappy with having to use FTDI’s FTD2XX, but there user’s have at least the choice of using the free libftdi, and all the hardware is documented.
These general reservations aside there are also a few things you should fix in your code:
The .speed member of the jtag_interface_t structure isn’t optional - it gets called whenever a users enters the “jtag_speed” command. If there’s no way for your target to implement throttling then provide a dummy function. This could also be the reason for the probems you’re seeing - how fast does your JTAG interface operate? The LPC’s use the ARM7TDMI-S which limits TCK to less than 1/6th of the core frequency - with your LPC213x and the PLL turned off this is somewhere between 2 MHz and 3 MHz.
Your protocol uses single bytes for values that could very well exceed 8 bit, like scan size (the current trunk code scans for devices in the chain with a 360 bit scan), runtest (the XScale code idles for 2030 cycles) or sleep (sleeps are specified in microseconds, and quite likely exceed 255us).
It unconditionally calls Windows specific functions (WSA*)
BOOL isn’t used anywhere else, and seems to be Windows specific, too (does it work with Cygwin?)
There are no asserts used in OpenOCD (we could discuss using them, but until there’s an agreement on how and when to use them I’d rather not use them)
As you mention, I need to clean up the code a little (it’s been tested only on Windows) and it could be a speed issue, I’ll look into that and implement the speed function.
I understand you are reluctant to include proprietary code, no problem either way.
I did a little work tonight. I fixed the speed function. I found I was actually under driving the JTAG (in term of speed). Now it flashes 100KB in 8s instead of 13s (dcc_downloads off). The ARM core runs at 24MHz, not sure if that matters for flash programming timing.
I’ve put asserts on the bytes to make sure they don’t bite me right now (and I changed the initial scan so that it looks only for a few devices).
My current guess is that the TCP stack is bitting me. “dcc_downloads” enabled makes the JTAG packets much bigger and I’ve already seen TCP screwing up for small packets, maybe it’s worse for bigger ones.
The .speed member of the jtag_interface_t structure isn’t optional - it gets called whenever a users enters the “jtag_speed” command. If there’s no way for your target to implement throttling then provide a dummy function. This could also be the reason for the probems you’re seeing - how fast does your JTAG interface operate? The LPC’s use the ARM7TDMI-S which limits TCK to less than 1/6th of the core frequency - with your LPC213x and the PLL turned off this is somewhere between 2 MHz and 3 MHz.
I got somewhat curoius about this topic. AFAIK, the LPC’s start up with a rather low frequency and can be configured to a higher frequency in the startup code.
This means for OpenOCD it would be desirable to change the speed dynamically: switch to a low frequency when chip is reset, but have the possibility (with a new command) to switch to a higher frequency. I think this could improve download spee greatly.
Would that be possible? Or do I miss something here?
It’s already possible to adjust the JTAG speed at any time during execution. Just add a “jtag_speed ” after you’ve made sure that the PLLs are enabled, and it will operate at the new speed.
Dominic:
It’s already possible to adjust the JTAG speed at any time during execution. Just add a “jtag_speed ” after you’ve made sure that the PLLs are enabled, and it will operate at the new speed.
Ah... Since jtag_speed is listed in the "configuration options" section, I thought it is an option, not a command.