MSP430F5438A: PMM SVSM strange behavior when enabled

tianshao ni

Hello!

We use the MSP430 to perform house keeping functions for our custom device. The MSP430 communicates with an external processor using SPI and receives code upgrade. We use the DCO as MCLK at ~22MHz, to support this, we step Vcore to level 3.

We've always disabled the SVSM for both high side and lowside(DVcc and Vcore ) to save power and we've noticed the MSP would occasionally hang. Interrupts doesn't work in this state. We also enabled the watchdog timer but it also wouldn't reset. This has been hard to replicate but we think it could happen in two ways:

We speculate that when the WDT issues a PUC, it could hang the MSP as mentioned here : https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/353287/msp430-hangs-up-even-when-wdt-timer-is-enabled. We currently don't have a handler for NMI/SNMI so not sure if OFIFG is happening. We're thinking of using the WDT as a timer and issue a soft BOR in the WDT interrupt handler, this way it won't issue PUCs. Would this work around prevent WDT from hanging the MSP and is it safe?
We may have MSP supply voltage drops, although without confirmation. Since we disable the SVSMs, we have no protection so I assume the MSP could hang if supply is unstable. Enabling the SVSMs cause a bunch of unexpected issues:
- If we enable the SVSM low side, it breaks the SPI communication. I thought this was because of a SVSM triggered POR/NMI so I set the entire register of PMMRIE to 0 and this still happens. Why would low side SVSM affect UCAx? Communication is fine if I connect the debugger, suggesting there's a supply issue. When I probed the external Vcore pin, I saw a steady 1.92V(level 3) when communication is failing, regardless of whether I have the debugger connected. Why would SVSM low side do anything if Vcore is stable?
- If we enable the SVSM high side, it breaks the MSP upgrade(through SPI comm, lots of flash writes). Again, I don't believe it's caused by a SVSM triggered POR/NMI since I set PMMRIE to 0. Why would high side SVSM affect UCAx? If I perform an upgrade while the debugger is connected, it works fine. I probed DVcc during an upgrade and I saw a steady 3.3V, regardless of whether I have the debugger connected. Why would SVSM high side do anything if DVcc is stable?

I've provided relevant code snippet below, this is essentially the same code as the MSPWARE PMM driver lib.

/// sets the PMM core to a specific voltage
/// @param[in] level the voltage level to set
/// @return success of the call
bool SystemClock::configVCore(uint16_t level)
{
uint16_t actual;
bool status = true;

// set mask for maximum level
level &= PMMCOREV_3;
// get actual
actual = (PMMCTL0 & PMMCOREV_3);

// increase or decrease step-by-step
while (((level != actual) && status) || (level < actual))
{
if (level > actual)
status = incVCore(++actual);
else
status = decVCore(--actual);
}

return true;
}

/// increments the vcore to a specified value
/// @param[in] level the level to set the vcore to
/// @return success of the call
bool SystemClock::incVCore(uint16_t level)
{
uint16_t PMMRIE_backup, SVSMHCTL_backup, SVSMLCTL_backup;
bool ret = true;

// the code flow for increasing the vcore has been altered to work
// around the erratum FLASH37.

// open PMM registers for write access
PMMCTL0_H = 0xA5;

// clear flags
PMMIFG = 0;
// set SVM highside to new level and check if a vcore increase is possible
SVSMHCTL = SVMHE | SVSHE | (SVSMHRRL0 * level);
// wait until SVM highside is settled
safeWait(&PMMIFG, SVSMHDLYIFG, false);
// clear flag
PMMIFG &= N16(SVSMHDLYIFG);

// check if a vcore increase is possible
if ((PMMIFG & SVMHIFG) == SVMHIFG)
{
// vcc is too low for a vcore increase so we will recover the previous settings
PMMIFG &= N16(SVSMHDLYIFG);
SVSMHCTL = SVSMHCTL_backup;
// wait until SVM highside is settled
safeWait(&PMMIFG, SVSMHDLYIFG, false);
ret = false;
}
else
{
// set also SVS highside to new level Vcc is high enough for a vcore increase
SVSMHCTL |= (SVSHRVL0 * level);
// wait until SVM highside is settled
safeWait(&PMMIFG, SVSMHDLYIFG, false);
// clear flags
PMMIFG &= N16(SVSMHDLYIFG);
// set vcore to new level
PMMCTL0_L = U8((PMMCOREV0 * level));
// set SVM, SVS low side to new level
SVSMLCTL = SVMLE | (SVSMLRRL0 * level) | SVSLE | (SVSLRVL0 * level);
// wait until SVM, SVS low side is settled
safeWait(&PMMIFG, SVSMLDLYIFG, false);
// clear flag
PMMIFG &= N16(SVSMLDLYIFG);
// SVS, SVM core and high side are now set to protect for the new core level
// restore low side settings, clear all other bits except level settings
SVSMLCTL &= (SVSLRVL0 | SVSLRVL1 | SVSMLRRL0 | SVSMLRRL1 | SVSMLRRL2);
// clear level settings in the backup register,keep all other bits
SVSMLCTL_backup &= N16((SVSLRVL0 | SVSLRVL1 | SVSMLRRL0 | SVSMLRRL1 | SVSMLRRL2));
// restore low-side SVS monitor settings
SVSMLCTL |= SVSMLCTL_backup;
// restore high side settings. clear all other bits except level settings
SVSMHCTL &= (SVSHRVL0 | SVSHRVL1 | SVSMHRRL0 | SVSMHRRL1 | SVSMHRRL2);
// clear level settings in the backup register,keep all other bits
SVSMHCTL_backup &= N16((SVSHRVL0 | SVSHRVL1 | SVSMHRRL0 | SVSMHRRL1 | SVSMHRRL2));
// restore backup
SVSMHCTL |= SVSMHCTL_backup;
// wait until high/low side settled
safeWait(&PMMIFG, SVSMHDLYIFG, false);
safeWait(&PMMIFG, SVSMLDLYIFG, false);
}

// clear all flags
PMMIFG &= N16((SVMHVLRIFG | SVMHIFG | SVSMHDLYIFG | SVMLVLRIFG | SVMLIFG | SVSMLDLYIFG));
// restore PMM interrupt enable register
PMMRIE = PMMRIE_backup;
// disable SVSMs to prevent hanging during upgrade
//SVSMHCTL &= N16((SVMHE | SVSHE));
//SVSMLCTL &= N16((SVMLE | SVSLE));
// lock PMM registers for write access
PMMCTL0_H = 0x00;

return ret;
}

Any guidance would be greatly appreciated!

Thanks,

Tian

over 4 years ago

0 Gary Gao over 4 years ago

TI__Mastermind 41940 points

Hi Tian

tianshao ni said:
Would this work around prevent WDT from hanging the MSP and is it safe?

The risk for this case is that the MCU hang up when execute some ISR or go into some interrupt but have no ISR, the WTD's ISR will not be executed. I recommend to make sure the ISR in your code to be short and make sure all the enabled interrupt or NMI to have ISR.

0 Gary Gao over 4 years ago

TI__Mastermind 41940 points

tianshao ni said:
Enabling the SVSMs cause a bunch of unexpected issues

For this issue, you can try two things here:

1. Check SYSRSTIV when start up that you can see if SVS trigger the POR when the SPI failed

2. Could you show me the register value of SVSMHCTL and SVSMLCTL after running the code in debug mode

0 tianshao ni over 4 years ago in reply to Gary Gao

Prodigy 120 points

Thanks Gary, we'll definitely take this into consideration.

0 tianshao ni over 4 years ago in reply to Gary Gao

Prodigy 120 points

Thanks for the suggestion Gary!

I put in handlers for UNMI and SNMI and the ISRs issue a BOR. The SPI comm is failing all the time with SVSM enabled but the MSP isn't resetting, so I don't think it's a SVSM interrupt or the POR, but something else that is related to the SVSM.

After boot up, the MSP would often run incVCore() 3 times to get to level 3, and after that I try to read c and SVSMHCTL and I read 0x4400 for both. So nothing out of the ordinary there.

0 Gary Gao over 4 years ago in reply to tianshao ni

TI__Mastermind 41940 points

Hi For SVSMHCTL and SVSMLCTL should not be 0x4400, the SVSHRVL and SVSMHRRL, SVSLRVL and SVSMLRRL, should be 0x3 as below

0 tianshao ni over 4 years ago in reply to Gary Gao

Prodigy 120 points

Hi Gary,

Thanks for the reply. I used the CCS view register tool and this time it looked correct.

0 Gary Gao over 4 years ago in reply to tianshao ni

TI__Mastermind 41940 points

I saw you create the function to configure the VCORE, how about to use the demo function that we used in our demo code like this https://dev.ti.com/tirex/explore/node?node=ACn5myI1UKFNTOYH3qcXnQ__IOGqZri__LATEST

And this is also a SPI demo code that you test on your side just modify the clock frequency to 22MHz and Vcore to level 3

0 tianshao ni over 4 years ago

Prodigy 120 points

Thanks Gary,

I used the same setVCoreUp() function as the example and the behavior is the same, SPI comm breaks. After some careful examination and probing, we found that the communications are in fact happening, for both SOMI and SIMO. Signal integrity looks fine. We're actually able to receive some transmission successfully but not consistently. The SOMI side appears to behave worse. Also, we found that if we attempt SPI communication at the same time as a bluetooth connection(uses UART from another USCI module), the MSP hangs(WDT doesn't work in this state as well). I can understand if lots of interrupts are happening, some transmission could be missed, but it shouldn't hang he MSP.

0 Derek over 4 years ago in reply to tianshao ni

Mastermind 9812 points

I recommend always enabling the WDT, even if at a long interval (e.g. 16sec) so if there's any SPI bus hangup, at least the '430 would restart. I also like reading out the reset reason and displaying it to console when the '430 starts; helps to see why it reset.

0 tianshao ni over 4 years ago

Prodigy 120 points

Thanks for the reply. We've made some improvements to our stability by handling NMIs and disabling SVSMs. I still have one question, although the SVSMs are disabled(SVMHE,SVSHE,SVMLE & SVSLE), I still enabled SVSHPE and SVSLPE. Would the POR still happen if voltage falls below threshold?

0 Gary Gao over 4 years ago in reply to tianshao ni

TI__Mastermind 41940 points

Sorry for the late response, if SVMHE,SVSHE,SVMLE & SVSLE are disabled, the POR will not be triggered by SVS.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5438A: PMM SVSM strange behavior when enabled