• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 79 subscribers
  • Views 5382 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.

MSP430F5419A entering and exiting LPM4.5

Igor Igor
Intellectual 675 points
Other Parts Discussed in Thread: MSP430F5419A

Hello 

I have a question regarding entering and exiting the LPM4.5 on MSP430F5419A.

I am attempting to enter LPM4.5 by the help of the following function:

 

void enter_LPM4_5(void)

{

  PMMCTL0_H = PMMPW_H;                      // open PMM

  PMMCTL0_L |= PMMREGOFF;                   // set Flag to enter LPM4.5 with LPM4 request

  

  __bis_SR_register(LPM4_bits+ GIE);

  __no_operation();

}

 

I put a break point at the beginning of the function and as described in SLAA424 set the debugger to "Release JTAG on Go" (using IAR 5.20.1)

Then I press run....The interface that shall wake me up from LPM is P2.1, and the iinterrupt on it is enabled...

Upon wakeup from LPM I see that the PMMREGOFF is set, but I am not running from the main(), but I run from interrupt handler for port 2.

Also I have noticed that the LOCKLP5 bit is not set. The system registers and internal RAM variables preserve their values so I assume that I am not entering an LPM4.5 but LPM4.

The question is what I am missing and why not entering LPM4.5?

The port2 handle is as follows:

 

case 4:

P2IFG &= (~BIT1);
P2IE  &= (~BIT1);
LPM4_5_WakeUP();
__bic_SR_register_on_exit(LPM4_bits);
__no_operation(); // For debugger

break;

 

where the wakeup function is:

void LPM4_5_WakeUP(void)

{

   volatile short wake;

   volatile unsigned int i = 0x1000;


   while(i--);

   

   wake = 1;

   while (wake);// SW trap for debugger..

  PMMCTL0_H = PMMPW_H;                      // open PMM

  PM5CTL0 &= ~LOCKIO;                       // Clear LOCKIO and enable ports

  PMMCTL0_H = 0x00;                         // close PMM


  // Clear pending interrupts

  P2IFG = 0;

  while (wake);

}

 

In general I assumed that I will not wakeup on port interrupt but will start from main() where the code handles the wakeup as follows:

 

void main(void)

{

 

WDTCTL = WDTPW+WDTHOLD;                   // Stop WDT

 

//////////////////////////////////////////////////////////////////////////////////

P2DIR |= BIT0;                            // MCLCK P2.0

P2SEL |= BIT0;                            

 

P2DIR |= BIT6;  // ACLCK P2.6

P2SEL |= BIT6;  

   ///////////////////////////////////////////////////////////////////////////////////


switch (__even_in_range(SYSRSTIV,SYSRSTIV_PMMKEY))

    {

   case SYSRSTIV_NONE:

     break;

   case SYSRSTIV_BOR:

     break;

   case SYSRSTIV_RSTNMI:

     break;

   case SYSRSTIV_DOBOR:

     break;

   case SYSRSTIV_LPM5WU:

     LPM4_5_WakeUP();

     break;

   case SYSRSTIV_SECYV:

     break;

   case SYSRSTIV_SVSL:

     break;

   case SYSRSTIV_SVSH:

     break;

   case SYSRSTIV_SVML_OVP:

     break;

   case SYSRSTIV_SVMH_OVP:

     break;

   case SYSRSTIV_DOPOR:

     break;

   case SYSRSTIV_WDTTO:

     break;

   case SYSRSTIV_WDTKEY:

     break;

   case SYSRSTIV_KEYV:

     break;

   case SYSRSTIV_PERF:

     break;

   case SYSRSTIV_PMMKEY:

     break;

    }

  ...

}

On general wake up I am rasing the PMM to Vcore Level 3 and the system  sourced by XT1 clock of 32768 Hz frequency, and SMCLK is DCOCLK/2, MCLCK is DCOCLK and ACLCK is sourced by XT1 directly (ACLK 32768, MCLCK ~24 MHz, SMCLCK is ~12 MHz). The system uses I2C, UART and SPI interfaces, which are re-configured upon entry into the LPM4.5 to be GPIO's....

Please help.

Regards,

Igor

  • 0
    Guru 12160 points

    Hi Igor,

    I noticed you mentioned UART.  Be sure to put the UART into reset before attempting LPMx.5.  The UART makes a clock request that effectively overrides your request for LPMx.5.  Instead, you actually enter another LPM where the UART clock keeps ticking (DCO or XTn) and the CPU regulator stays on.

    Jeff

  • 0 in reply to Jeff Tenney
    Intellectual 675 points

    Hi Jeff,

     

    Thanks a lot for the answer. I tried the following before entering LPM4.5:

    void prepare_to_LPM4_5(void)

    {

    // Reset the I2C interface to move to data out...

    P9OUT |= (BIT1 | BIT2);

    P9DIR |= (BIT1 | BIT2);

    P9SEL &= (~(BIT1 | BIT2));

    UCB2CTL1 |= UCSWRST;

    // Reset teh debug UART interface

    UCA1CTL1 |= UCSWRST; 

    P5OUT |= (BIT6);

    P5DIR |= (BIT6);

    P5SEL &= (~BIT6);


    P5SEL &= (~BIT7);


    // Reset the SPI 1

    UCA2CTL1 |= UCSWRST;

    P9DIR |= BIT0;

    P9OUT &= (~BIT0);

    P9SEL &= (~BIT0);

    P9DIR |= BIT4;

    P9OUT &= (~BIT4);

    P9SEL &= (~BIT4);

    P9DIR &= (~BIT5);


    // Reset the SPI 2

    UCB1CTL1 |= UCSWRST;

    P5SEL &= (~BIT4);


    P5DIR |= BIT5;

    P5OUT &= (~BIT5);

    P5DS  |= BIT5;

    P5SEL &= (~BIT5);


    P3DIR |= BIT7;

    P3OUT &= (~BIT7);

    P3SEL &= (~BIT7);


    // Reset the UART

    UCA3CTL1 |= UCSWRST;

    P10DIR |= BIT4;

    P10OUT |= BIT4;

    P10SEL &= (~BIT4);


    // Set the RTS

    (P9OUT |= BIT7);


    P10DIR &= (~BIT5);

    P10SEL &= (~BIT5);


    // Reset the last SPI interface used

        UCB0CTL1 |= UCSWRST;

    }

     

    void enter_LPM4_5(void)

    {

    prepare_to_LPM4_5();

      __enable_interrupt();                     // ensure that interrupts are enabled

      PMMCTL0_H = PMMPW_H;                      // open PMM

      PMMCTL0_L |= PMMREGOFF;                   // set Flag to enter LPM4.5 with LPM4 request

      LPM4;                                     // now enter LPM4.5

    }

     

    And nothing has changed in the behavior. I still wakeup as if I was only in LPM4...

    Any other ideas? May it be that I need to shut down XT1 and move to internal clock?

    What else can prevent me from going into LPM4.5?

     

    Regards,

    Igor

  • 0 in reply to Igor Igor
    Guru 12160 points

    Timers, including the watchdog timer, also make clock requests that can prevent LPMx.5.

    Pretty much any peripheral that uses a clock is worth an extra look.

    Jeff

  • 0 in reply to Jeff Tenney
    Intellectual 675 points

    I am not using WDT or any other timer.

    I have putted ALL the peripherals in use into reset (please take a look and let me know if I did it in a right way) or I need to clear all the configurations too?

    On top of that do I need to disable XT1 ?

    PMM is running on Vcore level 3 - shall I reduce it to level 0 as it is in default?

     

  • 0 in reply to Igor Igor
    Guru 12160 points

    XT1 usually isn't a problem.  However, make sure you leave XT1OFF set (the default).  Don't clear that bit.

    No, you don't need to reset other configuration items.

    No, you don't need to reduce the Vcore level either.

    It looks like you've put the UART into reset correctly.  (You also managed to put the SPI and I2C into reset, which isn't really necessary but doesn't hurt.)

    Sorry I'm running out of ideas.  Usually it's some peripheral making a clock request.

    Are you fairly confident in the "release JTAG on go" feature?  The JTAG debugger (specifically the TEST pin) can definitely prevent LPMx.5.

    Jeff

  • 0 in reply to Jeff Tenney
    Intellectual 675 points

    Hi Jeff,

    As originally stated the XT1 is on since we are running from external 32768 clock. 

    I have tried to add UCSCTL6 |= XT1OFF; but in such a case nothing wakes me up at all and i need to reset the board to be able to run again.

    In addition shall the PMM module be reseted to the default state?

     

    Thanks 

    Igor

  • 0 in reply to Igor Igor
    Guru 12160 points

    Hi Igor,

    I know you are using XT1, but you don't need to clear XT1OFF to use XT1.  If you leave XT1OFF set, XT1 will still run in AM through LPM3, as indicated in the first bullet point below.

    Anyway, I'm guessing you made it into LPM4.5 successfully with that change.  Now you just have to figure out how to wake up properly.  Don't forget that your code has an infinite loop in the wake-up routine, which could be very misleading without the debugger attached.

    Jeff

  • 0 in reply to Jeff Tenney
    Intellectual 675 points

    Thanks a lot Jeff.

    2 more questions: when shall I turn off the XT1OFF bit? According to the above - I may leave it always off (set) since XT1 is sourcing the ACLCK and the FLL only.The question is when shall I turn it off?

    Regarding the original problem - I am running with debugger since I want to verify that waking from LPM4.5.So toggle on P2 (with ISR enabled of course) shall wake me up.

    At the very beginning of the main I mux out ACLCK and connected with scope to the correct pin: in LPM3 I detect that the ACLK is running, but after the change of XT1 off (setting this bit, actually not touching it) I have noted that the toggle on corresponding PIO does not wake me up at all....

    Is my understanding correct that waking from LPM4.5 can happen with PIO and interrupt and the code will run from the main and not from the interrupt handler for the PIO and more then that, as long as LOCKIO bit is set, the interrupt vector will not be triggered (for the PIO)?

     

    Thanks a lot

    Igor

  • 0 in reply to Igor Igor
    Guru 12160 points

    The XT1OFF bit is set after reset.  You don't ever need to clear it if I understand your application correctly.  If you never clear it, then you never need to set it either since it starts out set.  If for whatever reason you decide to clear it, then be sure to set it again in your prepare_to_LPM4_5 function.  The XT1OFF bit must be set to enter LPMx.5.

    Anyway, I'm pretty sure the wake-up is actually working for you.

    Your code is executing an infinite loop before you unlock the I/O pins.  That's why you don't see ACLK on the pin.  Try your code without that infinite loop (and the other one below).

    It's tricky to use the debugger through LPMx.5.  The wake-up is a BOR, which disconnects the JTAG debugger.  CSpy (the PC application) doesn't know it got disconnected, so watch out.

    Yes, your understanding is correct that waking from LPM4.5 causes a device reset (BOR) which eventually leads back to main (not the PIO interrupt handler).  As for the LOCKIO bit, it locks the IO pins.  One side effect is that the input pin won't see edges that would normally cause an interrupt until you clear the LOCKIO bit.

    Jeff

  • 0 in reply to Jeff Tenney
    Intellectual 675 points

    Thank you so much for the help...

    You were right and I was able to figure out how to debug the code in LPM4.5...

    Just one more not related question: what is the ussage of the XT1OFF  bit?? If the MSP will request automatically the clock on XT1 as soon as device is sourcing some of its clocks with the XT1, then why someone will want to touch it? Why in the example code of MSP this bit is cleared for examples of ucs ussage with external code?

     

    Regards and thank you for the help,

    Igor

  • 0 in reply to Igor Igor
    Guru 12160 points

    Loosely speaking, XT1OFF = What should MSP430 do with XT1 when a crystal is present but is not currently being used?

    If an application continuously uses XT1, then there would be no need to mess with XT1OFF.  The clock request will keep XT1 ticking all the time in spite of XT1OFF being set.

    If an application never uses XT1, then there would be no need to mess with XT1OFF.  Likely the SEL bit for XT1 would not be set and the oscillator would simply be off anyway.

    However, an application that uses XT1 only occasionally can control what the MSP430 does with XT1 when it isn't actively being used.  The difference is how quickly the XT1 clock becomes available when it is needed.  If the MSP430 kept it ticking even when not in use, then it is available instantly when it is needed.  If not, it can take several hundred milliseconds for some crystals to become available (like LF tuning-fork crystals).  Because keeping XT1 ticking only costs a couple of microamps, most example code from TI just clears the XT1OFF bit as the most general solution for everyone.  However, as you found, that general solution prevents LPMx.5.

    Jeff

  • 0 in reply to Jeff Tenney
    Intellectual 675 points

    Thanks a lot

    Igor

**Attention** This is a public forum