I have some custom boards with an ARM processor (marvell78100, armv5 compliant), some SDRAM and some Flash. I'm trying to investigate timings problem with the SDRAM, since it seems the layout was not done correctly, which causes program crashes on some boards, every couple of hours.

Unfortunately, it's a typical situation of heisenbug, where observing the bug makes it disappear: when I run the program on gdb with a peedi JTAG debugger, the amount of errors seems to be extremely reduced.

What is the speed of a program running in a JTAG debugger compared to the normal speed?

I think I could find this information in the specifications for the ARM JTAG debug cells, but I didn't manage to find those specs.

  • \$\begingroup\$ Is this single-step, using software breakpoints, or hardware debug only? The first two will definitely slow it down. Does simply having the JTAG attached fix the bug? \$\endgroup\$ – pjc50 Apr 22 '13 at 9:02
  • \$\begingroup\$ I use "continue" with gdb, no breakpoints or single stepping. Running the program this way "fixes" the bug as it apparently changes timings. \$\endgroup\$ – Étienne Apr 22 '13 at 9:27

It depends on the kind of jtag interface that you have. In my experience, what I've noticed (happens on MSP430 and Atmel.ARM7TDMI) is that when you have watches on variables or breakpoints, or even any kind of control via the debugger, the core is halted periodically to run the boundary scan and all that. This will mess quite extensively with timing. If you have a free timer available, I'd suggest using its interrupt to toggle a pin every few microseconds and see whether this is happening and to what degree. Minimizing the number of breakpoints and watches may help, butI can't be sure of that. In fact, I have a feeling itll be target and IDE dependent also.

Timing issues such as this (RAM access) I'd suggest you investigate with an oscilloscope instead. Jtag is better used with slower events, algorithms, and places where the code can be safely halted.

  • \$\begingroup\$ I ended up using some LEDs to output errors, oscilloscope was not an option for me because the pins were under the components and some leads in the inner layers of the PCB. \$\endgroup\$ – Étienne May 18 '13 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.