I'll plug Valentin's response in below, as it's got tied to my erroneous
post (I always thought this was keyed on the message title, but seems to be
more than that?).
In the test code I was running, I was literally doing nothing more than the
bare minimum I needed to do to get the MSP running (disabling the watchdog,
waiting for its oscillator to stabilise), then dropping it into an LPM3
state. None of the timers where operational (unless their registers were not
initialised disabled, as I'd expect). Maybe there are multiple 'wait' states
that a reload can't totally recover from. Haven't any idea if this is
mspdebug related or not.
Re the PC question, since mspdebug can't communicate with the target
processor, its in no position to retrieve any context of what the target is
doing. I'm assuming anything trying to access via the JTAG is going to have
the same problem (unless this is somehow mspdebug specific?)
Andrew
From: Valentin Sawadski [mailto:valen...@tado.com]
Sent: Sunday, 24 November 2013 1:30 a.m.
To: and...@aratika.co.nz
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] LPM3 seems to interfere with MSP's ability to
restart
Hi
I'm not sure if it is directy related to your issue but one thing I noticed
when debugging targets with MSPGCC is the following.
My program is using Timer A and directly after programming the MSP with
mspdebug the Timer A is not starting up. It is simply not counting. I have
to powercycle the board to have it operate correctly. This happens every
time I program the MSP. Are you by any chance also using Timer A?
Btw have you tried to evaluate the program counter to see where it is stuck?
Best,
Valentin
-----Original Message-----
From: Andrew McLaren [mailto:and...@aratika.co.nz]
Sent: Thursday, 21 November 2013 1:13 p.m.
To: 'mspgcc-users@lists.sourceforge.net'
Subject: 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
LPM3 state.
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
instruction.
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
functioning.
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?
Andrew
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
