LPM x.5 mode sets itself - anyone seen anything like this?

Are you ever writing PMM/SVS/SVM registers in your code?

Are the PMM registers perhaps left open for writing (perhaps in a bootloader)?

Are the values written to PMM checked?

How is the exact sequence to write to the PMM/SVS/SVM registers?

Hardy

The numbering of the LPMs often leaves the impression of discrete LPM modes. There are none. The so-called LPMs are just a macro combination of several (originally independent) control bits.

So it is possible to enable the mechanism for shutting down the MSP without explicitely entering any LPM. It is possible to deactivate the clocks and crystals (as in LPM4) but not disabling the processor (which is part of all so-called LPMs) - provided that MCLK is switched to VLO before.

So it is possible to write something to the appropriate registers that causes an LPM4.5 lockdown even if no LPM ever was intentionally entered.
On the other side, you can unintentionally enter LPM if you push something on stack inside an ISR but do not pull it back before exiting. Then a wrong value is read back into the status register and violá, you're in an LPM.

So if you somehow successfully write any odd value to PM5CTL0 (maybe because of corrupted stack or array out of bounds), you'll get a port lockdown as if in LPM4.5, without ever having entered any LPM.

The description of the PMMPW password in the PMMCTL0 register is wrong. It is not that writing anything else than this will cause a PUC (as it is with other passwords). In fact, writing the correct password will remove the write protection from all PMM registers, writing a wrong password will write-protect the registers. (you see, none of the other PMM registers has a password and there is no separate lock/unlock bit in PMMCTL0, so the normal password mechanism makes no sense.)
This is correctly described right at the beginning of chapter 2.3. (But I didn't test whether there are really PUCs generated if writing is locked)

(I should file another documentation comment about this)

Hi Erik,

This sounds weird. By default it is not possible to accidentially slip into x.5 mode.

Is this a reproducible issue?

Thanks, Dietmar

HardyGriech said:

Are you ever writing PMM/SVS/SVM registers in your code?

Are the PMM registers perhaps left open for writing (perhaps in a bootloader)?

Are the values written to PMM checked?

How is the exact sequence to write to the PMM/SVS/SVM registers?

Good questions. 

- We write the PMM/SVS/SVM registers only during initialization, and

- the PMM control register is cleared when we're done. 

- The values written are pretty much all from immediate arguments, so they're not checked dynamically. 

- The exact sequence is utterly dull - write password, write desired values from immediate operands, clear password.  If you want the code snippet I'll provide it, but there's nothing interesting there.

Note that this is a device that had its battery attached & passed system test, then failed days later - PMM/SV register access was long in the past.

 

Dietmar Schneider said:

This sounds weird. By default it is not possible to accidentially slip into x.5 mode.

Is this a reproducible issue?

So far, we have seen it for certain on one device, and in retrospect we suspect it may have happened once before on a device that was accidentally power cycled before we could explore it adequately.  I'm engaged in trying (on another device) to go into LPM5 manually, come out with the lock bit set, and see if we can reproduce all the other observations we made.

Jens-Michael Gross said:

The numbering of the LPMs often leaves the impression of discrete LPM modes. There are none. The so-called LPMs are just a macro combination of several (originally independent) control bits.

So it is possible to enable the mechanism for shutting down the MSP without explicitely entering any LPM. It is possible to deactivate the clocks and crystals (as in LPM4) but not disabling the processor (which is part of all so-called LPMs) - provided that MCLK is switched to VLO before.

So it is possible to write something to the appropriate registers that causes an LPM4.5 lockdown even if no LPM ever was intentionally entered.
On the other side, you can unintentionally enter LPM if you push something on stack inside an ISR but do not pull it back before exiting. Then a wrong value is read back into the status register and violá, you're in an LPM.

So if you somehow successfully write any odd value to PM5CTL0 (maybe because of corrupted stack or array out of bounds), you'll get a port lockdown as if in LPM4.5, without ever having entered any LPM.

The description of the PMMPW password in the PMMCTL0 register is wrong. It is not that writing anything else than this will cause a PUC (as it is with other passwords). In fact, writing the correct password will remove the write protection from all PMM registers, writing a wrong password will write-protect the registers. (you see, none of the other PMM registers has a password and there is no separate lock/unlock bit in PMMCTL0, so the normal password mechanism makes no sense.)
This is correctly described right at the beginning of chapter 2.3. (But I didn't test whether there are really PUCs generated if writing is locked)

(I should file another documentation comment about this)

This is good information; thank you very much. 

However, I note that during our testing we have tried to write the LOCKLPM5 bit in PM5CTL0, and it cannot be set by being written.  It appears that it can only be set by writing to the PMMREGOFF bit, which is only writable via the password.  This is an awfully difficult sequence to accidentally generate, since we have no code that does this in our system - we couldn't just call bad code unexpectedly due to a stack glitch.

I also note that the x.5 bit is not included in the status register, so pulling in the wrong status via stack corruption seems unlikely to force us into x.5 mode.  I could easily imagine it putting us into one of the base LPM modes unexpectedly, but not into the LPMx.5 mode.

Erik Johnson said:

I also note that the x.5 bit is not included in the status register, so pulling in the wrong status via stack corruption seems unlikely to force us into x.5 mode.

No, of course., It was just an example for how you can get unexpectedly in any LPM and that LPM is just a macro name for cetain constellations of config bits.

Erik Johnson said:

I note that during our testing we have tried to write the LOCKLPM5 bit in PM5CTL0, and it cannot be set by being written.

Interresting. It is marked as R/W in the register description. It may be that it can be only written '0' but not '1' (this is not clear, but a possible interpretation) and is indeed only set by setting PMMREGOFF.

One other possible explanation I can imagine is that there was a something that not only restarted the chip, but also caused erratic behavior while the PMM password was still not cleared. I admit that this is a very unlikely case, yet not entirely impossible. Remember that some module configurations are not reset on a WDT reset. So a timer interrupt or such is immediately active again (and maybe even pending) as soon as you set GIE, even if the expected software flow didn't have the timer (etc.) configured yet. If an unexpected interrupt during PMM initialization causes erratic code execution, everything might happen.