LPM3 seems to interfere with MSP's ability to restart
Seemed to have managed to post this as a reply to another thread... Should
be here on its own!
I'm seeing a bit of a weird situation that I don't really understand. I
suspect it will be something simple (hopefully just a 'dumb user error'!).
It affects the ability of the debugger to reload/restart code following an
I've been able to reduce the logic to simply the command that triggers the
LPM3 state (I'm using C, so its just the LPM3 macro). As expected, the
command drops the MSP into lpm3, and the logic promptly hangs (there is
nothing there to exit this). This is running via mspdebug under Eclipse, so
if I pause the logic, I'll see that it is indeed sitting at the LPM3
If I terminate this and reload the code, all appears normal (the write/read
messages from mspdebug as it erases and reloads the code seem normal).
However, when the code is restarted, it appears to hang somewhere - it never
reaches the LPM3 instruction. This appears to have left the target MSP in
some sort of indeterminate state, and haven't found any way of retrieving it
other than power cycling the target. If I simply restart mspdebug, it
reports the following (this is using the TI FET, but have also tried an
Olimex JTAG-TINY with the same end result).
TI3140 device is in boot config, setting active
Ti3140: TI_OPEN_PORT failed: A device attached to the system is not
Ti3140: failed to set up port
I guess mspdebug is having issues communicating, and the problem is out with
the target msp. Powering the target MSP off and on clears the problem, but
haven't found anything else that does.
While the above is obviously contrived, many MSP's live most of their lives
in LP states, and LPM3 is possibly the most common of these. Any reload of
code while debugging is highly likely to be from something like LPM3, so
have to believe its something I'm doing. Any ideas?