Hi,
First, million thanks to Dominic and others who created OpenOCD. I’m trying out OpenOCD using AT91SAM7SE-EK and it is a greate software. However, I think I found a bug. How do I report a bug on OpenOCD?
Here is the description.
mww 0xfffffd00 0xa5000004 seems to cause the chip to respond slow to the JTAG port. (I’m not sure why) This causes arm7_9_execute_sys_speed to always re-read the debug the status register. However, usleep seems to sleep at least 1 ms since my USB2 based JTAG controller becomes as slow as USB1.1 based controllers.
I think it’s better to remove usleep function in the code since when using USB based JTAG controller, USB latency is enough delay anyway.
Thanks
bsp2020
Hi,
the OpenOCD polls the debug status register to identify re-entry into debug state after the system speed instruction completed. Normally, with a JTAG clock that’s considerably slower than the target clock, the core will have reentered debug state by the time the debug status register is read, and no additional delay will be introduced. If for some reason an access takes a lot longer, that additional milisecond isn’t going to hurt performance.
The situation is a bit different in your particular case. 0xfffffd00 is the reset controller, and you are trying to initiate a peripheral reset - I can only guess what happens inside the SAM7 when issuing this reset, but I guess it makes sense to expect them to stall the processor until all peripherals have been reset, which might take a while.
Did you check how often the debug status register gets re-read after issuing the write?
Regards,
Dominic
Dominic,
Thanks for the reply. I looked into this a bit more and found that once I write 0xa5000004 to 0xfffffd00, the JTAG access always needs 1 retry regardless of the duration of wait time (in other words, whether usleep is in the code or not). I’m sure that it is an issue with SAM7 since I’d expect the effect of the reset would go away soon (after a few milliseconds.) and it doesn’t. So, in my case, download of 28KB code takes about .5 seconds if I do not write 0xa5000004 to 0xfffffd00. But if I do write it to reset the peripheral. The download speed slows tremendously and takes 52 seconds. When I commented out the usleep statement, it’s more reasonable 1.1 seconds.
I’m sure that there is an issue with SAM7 which resetting the peripheral is having some side effect in JTAG communication. But, I also think usleep in the code is unnecessary since re-scanning using a USB based JTAG controller will add minimum 125 useconds (in USB2.0 and 1ms in USB1.1) anyway due to USB protocol latency. And since the minimum usleep delay seemds to be high (my guess is 1ms even though the code specifies 100us.), it’s probably better to remove it completely.
Thanks.
bsp2020
In OpenOCD revision 247:
in the readme.txt
I also found a confusing desription of Olimex-ARM-USB JTAG:
It states:
The Olimex ARM-USB-OCD offers support for a wide vriety of target voltages from
2.0V to 5V. It also allows targets to be powered from the ARM-USB-OCD and
features and additional RS232 UART.
Besides the marked typo,
I have one device and it’s documentation says
-
“supports ARM targets working in voltage range 2.0 – 5.0 V DC”
-
But power supply of that device one can jumper between 5, 9 and 12V!
So I am not sure if that is confusing only me… maybe one could explain how that works together!?
Is that “2-5V” related to the 20pin JTAG debug-interface?
How can the device adjust the 2-5 voltage, if I only can jumper the power voltage between 5/9/12V?
txh
tverrbjelke:
In OpenOCD revision 247:
in the readme.txt
I also found a confusing desription of Olimex-ARM-USB JTAG:
It states:
The Olimex ARM-USB-OCD offers support for a wide vriety of target voltages from
2.0V to 5V. It also allows targets to be powered from the ARM-USB-OCD and
features and additional RS232 UART.
Besides the marked typo,
I have one device and it’s documentation says
-
“supports ARM targets working in voltage range 2.0 – 5.0 V DC”
-
But power supply of that device one can jumper between 5, 9 and 12V!
So I am not sure if that is confusing only me… maybe one could explain how that works together!?
Is that “2-5V” related to the 20pin JTAG debug-interface?
How can the device adjust the 2-5 voltage, if I only can jumper the power voltage between 5/9/12V?
txh
You are actually refering to two separate things, the circuit board power supply and the ARM device operating voltage. The ARM-USB-OCD contains a power supply to supply voltage to the circuit board being tested. The circuit board being tested must also contain it’s own voltage regulator to provide power to the ARM device at the voltage that it needs. The ARM JTAG header has two pins that are at the same voltage as the ARM device on the circuit board. Those two pins determine the interface signal levels that will be used by the JTAG interface. So the “2-5V” specification is for the signal levels on the JTAG interface and the “5/9/12V” refers to the voltages available as raw power to the circuit board containing the ARM device.