I am currently using a Tiva C Series LaunchPad evaluation kit (TM4C123G) and have started experimenting with Keil's RTX RTOS. I use the on-board Stellaris ICDI debugger for my debugging purposes but as I add more features and breakpoints and start to monitor relatively large arrays, I notice that my monitoring on uVision really slows down which I suppose is to be expected.
My question is: Would I have any benefits in performance (for example, more breakpoints, faster monitoring) in switching from the ICDI to an external JTAG/SWD interface like a J-Link Edu debugger?
The reason I am asking is because I'm thinking of purchasing one eventually for real PCBs but would like to know if it would benefit me right now. I hope the question is clear, thanks!
Best Answer
The number of fast breakpoints is limited by the target. The Tiva™ TM4C123GH6PM microcontroller which is used on your board supports up to 8 hardware breakpoints.
If you set more than those, you end up with software breakpoints which work differently. There are different approaches, especially when executing from flash. A common approach is to insert a trap instruction, some architectures offer special breakpoint instructions for example the ARMv7-M has the
BKPT:Now inserting these instructions in code which runs inside the RAM is easy, but for code executing from flash, you have to reprogram the sector where you set the breakpoint. This is what the J-Link unit supports, other like Lauterbach debuggers as well. These have the added benefit, that they can be set in external flash as well (if supported by the debugger), which isn't always supported by hardware breakpoints. The breakpoint instruction will cause an exception, which is then caught by the debugger.
A different approach which is much slower is that the debugger switches to automatic single stepping and compares at each step if a breakpoint has been reached. This slows down the execution quite dramatically and the speed is limited by the JTAG/SWD clock, the slower the debug clock the slower your execution will be.
If you hit these limitations your debugging process will always slow down, but how hard depends on the debugger used. Some rely purely on software, so it gets even slower. Others will implement the software breakpoints in the debugging front-end hardware, so that it doesn't need to ask the PC all the time.
Transferring large arrays is mainly a function of the debug clock, but if your debug speed exceeds the PC to debugger interface, a debugging probe with internal buffers will help. It can read the array into the buffer at high speed and stream it to the PC at lower speed.
With that being said, I guess most on-board debugging probes are very limited in their capability. So they're likely to act as a relay for the PC which implements all the debugging protocol in the driver. A full-fledged debugger will implement the protocol in the firmware and use the available bandwidth to the PC more efficiently. So I'd say that a "real" debugger will likely increase the speed of the debugging process and make it a more pleasant experience.
I'm working with a Lauterbach debugger and it's so powerful and flexible that I'm only scratching at the surface of the capabilities.