MSP430 real time debug

The communiation between debugger and MSP is through JTAG. JTAG stops the CPU and emulates CPU microcode execution to get register values, memory contents etc.
It is a very slow and intrusive process.

It could be done to let the MSP execute auto-single-stepping through the code, updating everything each time, but then the MSP would just crawl.
Nothing left of 'real time'.

teh IAR MSP simulator will simulate a running MSP (not using the real hardware at all). Here you could see changes in memory or the processor state in 'real time'. However, the hardware modules aren't simulated too and of course no external events would be accounted for.

The mspgcc project works on a simulation feature too, and here the final goal is to simulate the internal hardware (including timers etc.). Maybe it will even access the physical port pins of an MSP through JTAG when the emulated CPU accesses the simulated registers. However, work has just started.

Hi Patrick,

No, I'm afraid it's a weakness of the Embedded Emulation Module (EEM) in the MSP430.  Maybe someday TI will invent an EEM+ with more of the features of full ICE.

Until then, when the JTAG host (PC) wants something, the EEM halts the CPU and then the JTAG host can use the EEM to go and get whatever it wants.  Meanwhile, the CPU is halted (like a breakpoint).  And the JTAG I/O is painfully slow.  All the while the CPU is halted.  Nothing the PC or FET can do about that.

The tools can try to make data updates as fast as possible and halt the CPU for the shortest possible time while updating the data on the PC screen, but all the mechanisms use breakpoints.

Jeff

Understood. Thanks guys!

pm

Please advice him other techniques, more suitable to real time debugging:

1) signalling events on chip pins - the signals can be captured by logic analyser,

2) logging on serial console

(1) is very effective and does not affect program behaviour but has limited ability to tranfer information. It is recommended for testing real time dependencies between threads, events etc.

(2) can transfer more data, developer selects points in code and textual form of printed information. It must be applied with care, to much logs will add a load to program that will change significantly performace.

Regards,
Piotr Romaniuk, Ph.D.
ELESOFTROM

PS
On some Texas Instruments DSP board I saw TRACE function, it was specialized chip with SDRAM. It was capable of recording a trace of execution in real time and did not affect the core. But it was for DSP not msp430.