• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 1106 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5528 SVS Resets

Daniel K.
Intellectual 425 points


Hello Community,


At first I didn't have any Problems. The DCO was running at 16MHz, I used the HAL Functions to SetVCore and Init_FLL_Settle. And everything was working fine, no resets, tested everything ... but the device was still connected to the Debugger.

So I was like, why is it not working without the debugger connected. And then I found it in the datasheet: theres a slow-wakeup and a fast wakeup. For my application to work I always need the fast wakeup.

So I set the SVM & SVS to perform the fast wakeup. But then the Problem occured, the device resets itself sometimes without any change in the Supply Voltage. So I read the Errata sheet, tried some workarounds but it didnt help.


But then I read if i use a slow DCO <=8MHz, I can disable the SVS low side. So I changed the clock to 8MHz, disabled DISABLE_SVSL_SVML(). Let i run for a day ... still get weird resets caused by SVSL.

Then I used DISABLE_SVSL_SVML + DISABLE_SVSL_RESET + DISABLE_SVML_INTERRUPT. Now i dont get any weird resets anymore. But I still dont know what the Problem is or if it still can happen that it resets.

My question is:

How should I set the SVM & SVS, when the DCO runs at 8MHz, and I don't really need the SVSL Protection, so i dont get unexpected Resets.

  • 0
    Intellectual 425 points

    Update:

    Even when i disable everthing, I still get SVSL PORs.

    The SYSRSTIV is always 0x00C. Even when it was a WDT Reset or RST.

  • 0 in reply to Daniel K.
    Expert 2665 points

    It looks like that revision of your part has PMM9 h/w bug (False SVSxIFG events). Did you implement workarounds for that? 

    > The SYSRSTIV is always 0x00C. Even when it was a WDT Reset or RST

    is probably happening because

    "A PUC/POR occurs after SVSx is disabled. After a PUC or POR the SVSx are enabled automatically but the settling delay does not get triggered. Based on SVSxPE bit this may lead to POR events until the SVS comparator is fully settled". 

    And yes, in general PMM is full of hardware bugs. When you read the errata section for PMM, it is scary... It looks like for some parts if you implement all workarounds, you will not be able to get fast wake-up at all...

    Also have a look on example files for driverlib. The pmm_ex2_FastWakeUp.c may have settings which will work for you.

  • 0 in reply to Serge A
    Intellectual 425 points

    I implemented all the workarounds. It seems to work now but i will test it over the weekend to be sure.

    Its really annoying, if I knew that before i would have used another Processor.

  • 0 in reply to Daniel K.
    Expert 2665 points

    Shouldn't be such bad :-)

    Try the function I use for PMM setup (the same code as in example I mentioned above). It makes use of driverlib though, but even if you don't use it, comments in the code still give you an idea about steps involved.

    #define FAST_WAKEUP

    void initPmm(void)
    {
    // Set Vcore setting required for 25MHz operation
    PMM_setVCore(PMM_CORE_LEVEL_3);

    #ifdef FAST_WAKEUP

    // PMM initialization

    // SVS Low side is turned off
    PMM_disableSvsL();

    // Monitor low side is turned off
    PMM_disableSvmL();

    // Monitor high side is turned off
    PMM_disableSvmH();

    // SVS High side is turned on - Default?
    PMM_enableSvsH();

    // Enable POR on SVS Event - Default?
    PMM_enableSvsHReset();

    // SVS high side Full perf mode,
    PMM_SvsHEnabledInLPMFullPerf();

    // Stays on in LPM3, enhanced protect
    // Wait until high side, low side settled
    while (PMM_getInterruptStatus(SVSMLDLYIFG + SVSMHDLYIFG) == 0);

    PMM_clearPMMIFGS();

    #endif

    }

    In general, PMM is not very easy to program correctly as it involves implementing of many workarounds fixing numerous h/w bugs. That's why it is better to do using driverlib as it looks like aware of these workarounds. Even TI's employees as far as I can see on theirs replies on the forum tend to use driverlib mostly for programming 2 peripherals: PMM and UCS, while using plain register manipulation for programming other modules.

    For newer processors (like FR5xxx family) the PMM module is totally redesigned, there are very few options left to be programmed, the rest is done automatically in hardware.

**Attention** This is a public forum