MSP430FR2422: clearing RTCIV

Hi Steve,

I recommend that you start with the working RTC examples for FR2422 in the TI resource explorer. You can find these here:

http://dev.ti.com/tirex/explore 

Hi Leonardo....

I did start with that.  I copied what I could use on my design from the example and now am trying to get to where I need to.  The users guide is clear to say that RTCIFG is cleared by a read to RTCIV.  The application code within the Resource Explorer for that product does nothing to clear the flag.  I have found that the application code from the explorer is not always well written.  I would like to know why the flag doesn't clear when a read to RTCIV is done?

For most of the IV registers a write is as good as a read and for some a write will clear all pending interrupts. Plus the optimizer will leave it alone.

My first guess is a debugger illusion -- it may be that the RTC is running while you're at a breakpoint, and the debugger can't do much of anything in less than a second. You might have to write some code which reads RTCIV twice in succession, then breakpoint at the end.

As David says, the RTCIV is unusual in that (at least according to the UG) you can't clear it using a write. I suppose it goes along with the fact that RTCIFG is the only IFG I know of which can't be explicitly cleared -- you can only clear it by reading RTCIV.

In the RTCCTL and other registers what does it mean when it shows the bit values at boot up with the curly braces {0} ?  I find it odd also that when I first load my code the RTCIE is enabled.  It seems it comes up at reboot as enabled.  I find that I have to write to RTCCTL to clear the enable....Doesn't that seem odd?

The debugger reset doesn't stop the RTC, I suppose it's more like a PUC than a POR.

The FR2433 Launchpad (and some others, I think) came with a demo which used the RTC, and the first time I loaded my own program in, it failed at isr_trap since RTCIE was still set. It was a good head-scratcher for a few minutes.

[Edit: Sorry, I missed the other question. The notation is described in User Guide (SLAU445I) Table 0-1..]

Let me ask you this.....

Should I be able to do the following?

At power up wait until a switch is pushed.  After switch is pushed have a pwm operate for a period of time (this is governed by a counter in the RTCIV).  After this expires within the RTCIV I would then invoke LPM3.5 by setting PMMREGOFF.  I would like to come awake then again by the use of the same switch that was pushed earlier and at this action I would like the RTCIV to count to a different value.  So for instance you push 1.4 the PWM will operate for let's say 1/2 hour, then I go into LPM3.5 for a really long time let's say 50 hours (let's say all RTC registers stay the same (ie 30 minute interrupt) it is just a count variable that changes here).  At the same time as LPM3.5  is running and you are in the 50 hour window I would like the a press of 1.4 to awake you and turn on the PWM again.  

Questions:

Is the above possible to do in code or won't the RTC allow me to do this?

Just prior going into LPM3.5 do I have to use some form of *(unsigned int *)BKMEM_BASE and if so how do I use this?  (I care about P1.4 having a pulldown and being interrupt capable)

My next question is if I have a count variable within the RTCIV how do I store that value into let's say backup memory so that when I come out of LPM3.5?

thanks

BAKMEM is memory that survives LPM3.5. [Aside: If you turn off the RTC, you're in LPM4.5 instead, and BAKMEM doesn't survive that.] Example msp430fr235x_lpm3_5_01.c uses it to store the contents of P1OUT (really BIT0, which is the LED) so it can reinstate it, toggle it, then save it again. It sounds as though your RTC count might be appropriate for this.

Data sheet (SLASEE5C) Sec 6.10.10 says you have 32 bytes of BAKMEM (word aligned). There are names for each of them, but it's probably easier to use it as an array (bytes or word) located at BKMEM_BASE. Just store something before LPM3.5, then -- only if restarting from LPM3.5 -- fetch it again.

[Edit: The linker gives me a warning, but it seems to do the right thing:

#pragma LOCATION(survival_kit,BKMEM_BASE)
#pragma NOINIT(survival_kit)
unsigned survival_kit[32/sizeof(unsigned)];

]

---

As for the longer question, I'm afraid I lost track partway through. I don't see anything obviously infeasible. You should probably draw it to make sure you've got all the cases covered.