MSP430FR57xx and LPM3.5

Further informtion. I now find that when the "minute change" interrupt occurs the processor resets, for some reason. It goes back to the start of teh program waiting for some input. However, theUIF-FET has crashed and the debugger needs to be re-started.

Peter

A little more. I re-enabled the WDT which made the system reset when it went into LPM3.5. Now it just sits there. I have put a break point on each of the interrupts and it does not get to any of them.

Peter

I have read through the power management module and note that the Vcore stays high when in JTAG mode (which I am using so I can debug my program.) Does this mean that it will not go into LPM3.5?? Or is it that it will go into this mode but the current draw will still higher than normal?

Thanks

Peter 

PeterG said:

When setting the alarm registers it says to set the AE to 0 if you wish to enable them. It should be set to 1.

Where in the guide did you read this?

Chapter 13.2.2 (Alarm function) tells that various types of alarms can be generated by setting AE.
The examples tell that you have to set AE for those alarm registers that are important for your alarm, and to clear it for those which are unimportant.
The notes further down only tell you to first clear all alarm registers including the AE bits before you program a new alarm or change the time, to avoid erroneous alarm events. When finally writing the new alarm, of course the AE bits must be set accordingly.

So everything is well with the guide.

Well, I have rev. a of the guide from 03-2012 (slau272a.pdf), but I don't think they have changed it to the worse in any newer revision.

I have rev c and if you go to 13.3.19 (register RTCMIN) you will see that it says O to enable, 1 to disable. It is on page 400.

Luckily I have been around a while and seen many mistakes in manuals, but it still wastes time when starting on a new chip.

Thanks

Peter

PeterG said:

I now find that when the "minute change" interrupt occurs the processor resets, for some reason.

In LPM3.5, the whole CPU shuts down except for the RTC and the XT1 crystal. All RAM content is lost, all module configurations are lost except the current internal state of the port and RTC registers. So when the interrupt wakes from LPM3.5, the MSP starts up like after a power-on (it actually is a power-on for most of it), but the RTS registers are locked (their content does not affect the RTC operation) until you properly reconfigure them and then unlock them, so the RTC can continue undisturbed.

Since the MSP shuts down, including internal supply voltage for CPU, memory, JTAG interface, it is no wonder that the debugger loses connection to the MSP, as if you just removed the chip form the PCB.

PeterG said:

I have rev c and if you go to 13.3.19 (register RTCMIN) you will see that it says O to enable, 1 to disable.

Okay, on Rev.A there was no register description at all for these registers (and the text clearly and correctly states how to use these bits) . Apparently someone made a mistake when adding this information to the register description.

By reading the module description, this discrepancy would have been obvious. Even for correct register descriptions, it is dangerous to just look at these and ignore the module description text.

Hi

Thanks for the reply. when I first started using micro's the term set and clear referred to setting the active state and sometoimes logic was positive and sometimes negative. I always try and find out whether they mean a 0 or a 1. For this I use the registers. I also go there to determine what is the reset state. I did find out about the JTAG not being available under LPMx.5. In my opinion the registers are a better choice than the text. In this case it was wrong because the user guide was wrong.

I assume you have used these chips before. In my project I substituted a loop for the entry into LPM3.5 so I could continue and develop the software. I am using RTCTEVIE interrup and doing so every minute. That works fine with the loop in place. According to the user guide (rev C 13.2.6) I set up the required interrupt, then enter LPM3.5. I also clear LOCKLPM5 before hand. When this interrupt occurs it goes into a BOR sequence, The RTCCTL01 is not retained (according to the user guide). My question is where does the Program counter end up? If it is a BOR I would assume it would start at the RESET vector, the start of my program. IS this where the code should be inserted to carry out point 5 in 13.2.6?

When I have used LPM's before I am used to setting them within the program and clearing the LPM bits in an interrupt routine according to some condition. Tha is, it then comes out of the LPM and you can then process data and back to LPM again. I know exactly where I am. With the FRAM chips it is not clear, to me, where I end up. Do I need to clear the LPM bits anywhere?

Thanks for the help

Peter