2
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\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
    Commented Apr 22, 2013 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
    Commented Apr 22, 2013 at 9:27

1 Answer 1

1
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\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
    Commented May 18, 2013 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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