This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP-EXP430FR2433: After downloading, does LaunchPad HOLD target in reset? Then does starting debugger reset it again?

Part Number: MSP-EXP430FR2433

My main.c code is below.  

If the debug probe is resetting the target after loading and letting it run, then when I later start the debugger, the target WAS in LPM and the first clause of the if is executed. My question is just to confirm that is what is happening.


If that is so, is there a way to start the debugger so that the target is in POR reset, and I can step through the second clause of the if?  I suppose I can just make the debugger jump to the else clause.

Context: Using CCS Cloud, MSP-EXP430FR2433.

if (PPMIFG.PMMLPM5IFG is set ) {
// wake from sleep // off chip resources still configured } else { // must be POR // configure off chip resources } LPM4;


  • Hi lloyd,

    I guess you are not posting the real source code here: if (PPMIFG.PMMLPM5IFG is set ), which doesn't follow the C grammar.

    The PPMIFG.PMMLPM5IFG bit is indicating an exiting from LPMx.5, which includes conditions on section 1.4.3.2 of the FR2433 User's Guide.

    If you click the Hardware Reset of the debug mode in CCS or enter LPMx.5 in  your code. The  PPMIFG.PMMLPM5IFG will be set after the device reset or wake up from LPMx.5. Then it will run into the first clause of the if code. 

  • The question is about the sequence of events when you download code to the target.  Is the sequence?

    debug probe assert nRST/NMI pin to hold target in reset

    debug probe uses SBW to write code to ROM/FRAM

    debug probe releases nRST/NMI pin and target executes, starting in the reset state but with PMMLPM5IFG clear

    code executes else clause and enters LPM

    user starts debugger  (gdb).  debug probe asserts and then lowers nRST/NMI pin but that does not clear PMMLPM5IFG bit

    code executes then clause

    In other words, the PMMLPM5IFG is only cleared when you cycle power to the Launchpad, which only happens once when you plug in the debugger probe/Launchpad.  A reset from the debugger probe does not clear the PMMLPM5IFG flag?  So the only way to step through the else clause using the debugger is to force the debugger to jump to it?

    I am just discussing that debugging LPM may require some special techniques using the debugger.

  • The Examples (SLAC700C) use:

    > if (SYSRSTIV == SYSRSTIV_LPM5WU) // When woken up from LPM3.5, reinit

    which clears the IV indicator. It may also clear that IFG (I haven't looked).

    Using this, I've had no particular trouble debugging LP3.5/4.5.
  • Good idea. The user's guide says you can use PMMLPM5IFG -OR- decode SYSRSTIV to determine . I was using PMMLPM5IFG simply because it seemed simpler and DriverLib supports it. There is an advantage to use SYSRSTIV, the two techniques are not equivalent? Even if you are in LPM, SYSRTSIV will generate SYSRSTIV_RSTIFG instead of SYSRSTIV_LPM5WU when the debugger probe resets?
  • Sorry, I missed the part about re-connecting. I've always just let it sit there.

    Yes, that sounds like a conundrum: (1) you want to clear the IFG/IV as soon as you see it but (2) since the IFG is defined in sec 1.4.3.2 to be set on Exit from LPMx.5 it won't be set for the debugger RST (conspicuously absent from the bullet list).

    To the uninitiated it seems like it would have been better to set it on Entry. I suppose you could set it yourself on Entry (ew, gross).

**Attention** This is a public forum