MSP430FR5969 LPM3 stops tick on RTC_B demo

[jimpx225 0]

moving on on my project i have dropped to power down to 7.6uA now i have a problem with the RTC_B PrintOncePerSec , if I add the LPM3 any ware in the code it stops the interrupt.

 

I have done some test and if i let the RTC count upto 10 then LPM3 the RTC stops after 10sec.

 

 

I have an Interrupt wake up from the push button which works fine so I am guessing the LPM3 is stopping the RTC.

 

 

#include <RTC_B.h>
int cnt =0;
void setup() {
 
   WDTCTL=WDTPW+WDTHOLD;
 
       P1OUT = 0;
  P1DIR = 0xFF;

  P2OUT = 0;
  P2DIR = 0xFF;

  P3OUT = 0;
  P3DIR = 0xFF;

  P4OUT = 0;
  P4DIR = 0xFF;

  PJOUT = 0;
  PJDIR = 0xFFFF;
   
 
 pinMode(P1_0,OUTPUT);

  rtc.begin();
  rtc.attachPeriodicInterrupt(1, flagTick);  // Runs flagTick() once per second
}

volatile boolean tick = false;

void loop() {
  if (tick) {
    
    tick = false;
    cnt = cnt +1;
  }
  else{
 
  _BIS_SR(LPM3_bits | GIE);     <<<< this stops the RTC tick
 
  }
   
 
  if (cnt ==5){
    
       digitalWrite(P1_0,HIGH);
 
  }
  if (cnt ==7 ){
    
         digitalWrite(P1_0,LOW);
    cnt=0;
   
                                           <<< I tried LPM3 in here same problem
  }
}

void flagTick()
{
 
  tick = true;

}

[spirilis 1,265]

Inside your flagTick function, try adding wakeup() before it exits.

[spirilis 1,265]

That feature isn't really documented properly so I will add it. I wrote the RTC_B library FYI.

[jimpx225 0]

That feature isn't really documented properly so I will add it. I wrote the RTC_B library FYI.

Are some you could answer one of my next question.   how to setup a 2 or 4 hr Alarm.

 

I guess you let me know when you have updated the doc.

[spirilis 1,265]

Github updated.

[spirilis 1,265]

Are some you could answer one of my next question.   how to setup a 2 or 4 hr Alarm.

 

I guess you let me know when you have updated the doc.

For a consistently reliable 2-4 hour alarm that runs in perpetuity, I would recommend basing it on a 1-second periodic tick interrupt.  The problem with using attachScheduledInterrupt is you constantly have to advance the day counter and that may vary based on what month it is (it won't "roll over" properly if you, say, add 1 day to the 30th or 31st, it'll clamp it at 31 if applicable).

 

Example:

volatile uint16_t _4hr_ticker = 0;
volatile boolean dostuff_every_4hr = false;

void flagFourHourTick() {
  _4hr_ticker++;
  if (_4hr_ticker >= (4 * 60*60)) {
    _4hr_ticker = 0;
    dostuff_every_4hr = true;
    wakeup();
  }

and up in setup() perhaps:

rtc.attachPeriodicInterrupt(1, flagFourHourTick);

and your loop() might have a:

if (dostuff_every_4hr) {
  // ....
} 

That flagFourHourTick can be as complicated as you need it to be.  If you do have more complex scheduling needs, the attachPeriodicInterrupt() might run a master function which runs several others which all manage their own counters and flag other stuff (e.g. their own dostuff_every_xx)

Any one of those can run wakeup() to wake the CPU.  The CPU wakes up once the initial handler function (the one passed to attachPeriodicInterrupt) exits.

[jimpx225 0]

For a consistently reliable 2-4 hour alarm that runs in perpetuity, I would recommend basing it on a 1-second periodic tick interrupt.  The problem with using attachScheduledInterrupt is you constantly have to advance the day counter and that may vary based on what month it is (it won't "roll over" properly if you, say, add 1 day to the 30th or 31st, it'll clamp it at 31 if applicable).

 

Example:

volatile uint16_t _4hr_ticker = 0;
volatile boolean dostuff_every_4hr = false;

void flagFourHourTick() {
  _4hr_ticker++;
  if (_4hr_ticker >= (4 * 60*60)) {
    _4hr_ticker = 0;
    dostuff_every_4hr = true;
    wakeup();
  }

and up in setup() perhaps:

rtc.attachPeriodicInterrupt(1, flagFourHourTick);

and your loop() might have a:

if (dostuff_every_4hr) {
  // ....
} 

That flagFourHourTick can be as complicated as you need it to be.  If you do have more complex scheduling needs, the attachPeriodicInterrupt() might run a master function which runs several others which all manage their own counters and flag other stuff (e.g. their own dostuff_every_xx)

Any one of those can run wakeup() to wake the CPU.  The CPU wakes up once the initial handler function (the one passed to attachPeriodicInterrupt) exits.

 

 

Thanks for the help ,

 

I have added a sleep(1000000); into the loop to put the MSP in to low current mode because if i add any form of LPM3 the tick ISR stops, do you think this is ok.

[spirilis 1,265]

Thanks for the help ,

 

I have added a sleep(1000000); into the loop to put the MSP in to low current mode because if i add any form of LPM3 the tick ISR stops, do you think this is ok.

Yeah, that's using Energia's sleep feature as intended... still a little curious why straight LPM3 isn't working but who knows (besides millis not incrementing properly?)