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.

MSP430FR5736: Problem to enter and exit LPM4.5

Part Number: MSP430FR5736
Other Parts Discussed in Thread: MSPWARE, MSP430FR5969, MSP430FR5739

Hi,

My customer is having difficulties to get the MSP430FR5736 to enter/exit LPM4.5.

The code is running on a custom board, and has been stripped from its original application to isolate the problem around the LPM4.5 functionality.

The attached code below has been tested both with and without an emulator connected. In both cases the current consumption by the MSP is still stable at around 5 uA after the attempt to enter LPM4.5. We believe that all I/O pins are pulled up/down correctly and the problem is not related to HW but rather has to do with the SW used to enter LPM4.5. For some reason it looks like the MSP is still alive and responsive on the JTAG interface after the LPM4.5 code has been executed. As I have understood it, this shouldn’t be possible, correct?

The example below is based on the following version of MSPWare 1_60_03_07.
Pin P2.2 is configured as an LPM interrupt to wake up the MSP from LPM4.5 on a falling edge. But there seem to be problems with both entering LPM4.5 and, if we are entering it something is strange during exit:

-          After the LPM4.5 code has executed the power consumption remain at 5uA and it is still possible to access the MSP using the debugger.

-          No BOR is detected when a falling edge is forced to P2.2.

Please have a look at this short example and advise us on what might be wrong in the way we try to enter LPM4.5.

Thanks and regards,

Joakim

 

------------------------------------------

#include <driverlib.h>
#include "inc/hw_regaccess.h"

 

//******************************************************************************

//!

//!   Empty Project that includes driverlib - Test LPM4.5 for MSP430FR5736

//!

//******************************************************************************

 

static void SetLPM4_5(void)

{

    // Close down inactive modules

    WDTCTL  = WDTPW | WDTHOLD;                // stop watchdog (do this first)

    DMA0CTL = DMA1CTL = DMA2CTL = 0u;        // Turn off DMAs

    TA0CTL = TA1CTL = 0u;  // turn off timers

    RTCCTL0 = 0u;                            // turn off RTC

    REFCTL0 &= ~REFON;      // turn internal voltage REF module OFF

       

    // Stop clock functions

    CSCTL0 = CSKEY;   // access password

    CSCTL1 = 0u;    // clear

    CSCTL2 = SELA_1; // Select VLO for ACLK

    CSCTL4 = 0u;    // clear all bits

    CSCTL4 |= (SMCLKOFF);    // set some bits

    CSCTL5 &= ~(XT1OFFG);   // clear clock faults

    CSCTL6 = 0u;    // all REQEN's off

    HWREG8(CS_BASE + OFS_CSCTL0_H) = 0x00;   // lock CS registers

 

    // Ports off

    P1OUT = 0x00; P2OUT = 0x00; PJOUT = 0x00;

    P1DIR = 0xFF & ~(BIT6); // set as outputs

   

    // Setup LPM interrup I/O

    P2IE |= (BIT2);     //enable Port interrupt

    P2IES |= (BIT2);    //interrupt on falling edge

    P2IFG &= ~(BIT2);   //clear interrupt flag

 

    // Disable SVS

    PMM_disableSVSL(PMM_BASE);

    PMM_disableSVSH(PMM_BASE);

    PMM_regOff(PMM_BASE); // PMMREGOFF = 1. Used for LPMx.5

   

    __bis_SR_register(GIE+LPM4_bits);             // Enter LPM4

}

 

int main(void)

{

    WDTCTL = WDTPW | WDTHOLD;                 // Stop WDT

 

    // check PMM state after reset

    if (PMM_getInterruptStatus(PMM_BASE, PMMRSTIFG))

    {

        PMM_clearInterrupt(PMM_BASE, PMMRSTIFG);

    }

   

    // check PMM state after BOR

    if (PMM_getInterruptStatus(PMM_BASE, PMMBORIFG))

    {

        PMM_clearInterrupt(PMM_BASE, PMMBORIFG);

    }

 

    // Have just exited from LMP4.5?

    if (PMM_getInterruptStatus(PMM_BASE, PMMLPM5IFG))

    {

        __no_operation(); // Set breakpoint here to trap BOR condition

       

        PMM_unlockLPM5(PMM_BASE);

        PMM_clearInterrupt(PMM_BASE, PMMLPM5IFG);

        PMM_regOn(PMM_BASE);

        PMM_enableSVSL(PMM_BASE);

        PMM_enableSVSH(PMM_BASE);

    }

   

    SetLPM4_5();

    __no_operation();

 

    while (1)

    {

      // Will only be here when in active mode

        __no_operation();

    };

}

 

// Wake up port pin interrupt

#pragma vector=PORT2_VECTOR

__interrupt void Port2_ISR(void)

{

  P2IFG &= ~(BIT2); //clear interrupt flag

 

  // enable this code if active mode required

  //PMM_regOn(PMM_BASE);

  //LPM4_EXIT;

}

 

#pragma vector=PORT1_VECTOR

__interrupt void Port1_ISR(void)

{

  __no_operation();

}

  • Hi Joakim,

    The current consumption and behavior that you are seeing on wake (no BOR) sounds like you may only be getting to LPM4 and not LPM4.5. PMM_regOff is the function that I see you using to turn off the regulator, which is essentially the difference between going to LPM4 and LPM4.5 - can you share what this function looks like?

    Could you have any other modules still on in the part? You could potentially try clearing the clock request enable bits in the CS module to see if you are then able to truly enter LPM4.5.

    Regards,
    Katie
  • Hi Katie,

    Thanks for helping out here. I'm attaching the source code for the function PMM_regOff, which is an MSPWare function from version 1.60.03.07:

    /*****************************************************************************

    //

    //! \brief Turns OFF the low-dropout voltage regulator (LDO) when going into

    //! LPM3/4, thus the system will enter LPM3.5 or LPM4.5 respectively

    //!

    //! Modified registers are PMMCTL0 .

    //!

    //! \param baseAddress is the base address of the PMM module.

    //!

    //! \return None

    //

    //*****************************************************************************

    void PMM_regOff(uint32_t baseAddress)

    {

            HWREG8(baseAddress + OFS_PMMCTL0_H) = PMMPW_H;

            HWREG8(baseAddress + OFS_PMMCTL0) |= PMMREGOFF;

            HWREG8(baseAddress + OFS_PMMCTL0_H) = 0x00;

    }

    The customer has also tried to clear the clock request enable bits in the CS module but still with the same result, unfortunately. Should this actually disconnect clocks or just prevents new requests from coming in?

    Any other suggestions on what we should try to get the device into LPM4.5?

    I looked in the examples available in the latest version of MSPWare, but cannot find any LPM4.5 example only LPM4. If we could get a working LPM4.5 example the customer could modify that to run on their HW. Do you know if such an example exist?

    Thanks and regards,

    Joakim

  • Hi Katie,

    Do you know if we have any LPM4.5 examples?

    If not, how do you suggest that we go ahead and verify whether the customer is entering LPM4.5 or not? I mean, their is still a small risk that the high current comes from an I/O pin (but this should have already been checked), so only looking at the current is not perfect.

    Best regards,

    Joakim

  • Hi Joakim,

    Sorry for the delay. Unfortunately the only way to tell if you are in LPM4.5 is by the current consumption and seeing that there is a reset when the interrupt occurs. I did find that we provide two LPM4.5 examples for the MSP430FR5969 device: dev.ti.com/.../

    If you use the example msp430fr59xx_lpm4-5_02.c as an example, porting it for your device (should have to change some pins, maybe some clock settings since the CS module is slightly different) I was able to see the correct LPM4.5 current consumption from the MSP430FR5739 datasheet. If you use the msp430fr59xx_lpm4-5_01.c as an example, you will see a slightly higher current consumption because the SVS is still on (but still less than 5uA).

    I hope that this helps.

    Regards,
    Katie
  • Hi Katie,

    The customer has ported the example to their custom board, but still with the same result -> No BOR.

    A question about the configuration of the JTAG interface. With the release build of the code customer use PJ.0, PJ.1, PJ.2 &  PJ.3 for PCB identification resistors and in the debug build they use these common pins for the JTAG/emulator. Are there any issues relating to the BOR and the JTAG interface that they might be running into here?

    Thanks and regards,

    Joakim

  • Hi Joakim,

    Are you saying that there are pullup/pulldown resistors on the Port J pins that are also used for JTAG? I would strongly advise against this as our programming tools are only tested with the recommended connections on the JTAG pins, not with anything else hanging off of them. In addition, if your code is following the LPM examples, these pins are likely being set as output low by software - if you have a resistor pulled up to Vcc then this will consume some current. I would recommend removing the resistors and see what happens in that case.

    Are you having the issue going to LPM only when in debug mode?

    Regards,
    Katie
  • Hi Joakim,

    Any update here? Did they remove the resistors?

    Regards,
    Katie
  • I'm going to close the thread due to inactivity, but please post back if you have an update.

**Attention** This is a public forum