MSP430F5335 RTC Stops running

Hello Jace,

Thank you for your quick response.

I am currently not using any LPMs yet. This issue may be occurring between main power cycles of the unit. The VBAT pin is always powered through a separate battery. I have not been able to pinpoint exactly when the problem first start. I have tested several units through our environmental test chamber during production test and have not seen this problem. It is now showing up while doing standard production testing.

As far as I can tell, I have XT1 setup properly for the 32KHz crystal. I have test options to interactively change the internal loading capacitors over the serial port. I can put a frequency counter on the ACLK output and see it move up and down as I select the various capacitors so I am sure that XT1 is running. All of the oscillator fault indicator bits are cleared as you can see in the MSP register values that I attached in my original post.

I have also confirmed that the RTCHOLD bit is cleared in RTCCTL01 and the LOCKBAK bit is cleared in BAKCTL.

I used the referenced application note as a guide when I originally added the preliminary support for the MSP real time clock. I implemented testing routines to determine after a power cycle if the RTC date time was maintained through the power cycle or not.

Currently I think my problem is possibly unrelated to the details of the app note. I connected an external 12 volt battery to the system and brought it back to my desk from our production department to keep from cycling the power. I then connected the IAR IDE through the TI MSPFET JTag and connected to running target. I then paused execution and observed the register values that were included in my original post. I also inspected the status that was detected the last time the board was powered. It appears as though the oscillator fault flag was clear on the last boot and BAKMEM0,1,2,3 had the preset values retained that I am putting in them. The last boot appears to have been a normal power cycle while the backup system was maintaining the RTC.

I have found that you can write a new date time to the RTC registers and it will be retained but does not increment.

I am using the TI MSP430 driverlib to configure the PMM so hopefully the PMM and SVS settings are correct.

It has been a while since I was down deep in all of the register settings required for the RTC to run, but I just can't put my finger on any register setting that looks to be incorrect.

Thanks,
Greg Dunn

I have discovered one other piece of information that may be useful this morning. Once the RTC is in the mode where it is no longer updating (incrementing), even though the XT1 32KHz crystal is running, LOCKBAK=0 and RTCHOLD=0, the only way that I have been able to get it running again is to remove the main power and the VBAT power. I can cycle the main power (DVCC and AVCC) all that I want, but the RTC only holds the last values written to the date time registers, they never increment. Only when I remove DVCC, AVCC and VBAT, then repower can I get the RTC to work properly.

Thanks,
Greg Dunn

Jace,

Thank you for your reply. I have read through the SLAA665B application report several times and will definitely review again. As far as I know, my code is doing everything like the example code except verifying the calibration registers right now. I plan to implement the calibration feature in the future so I planned to add that part then. The code does appear to properly detect normal power cycles as well as complete power cycles where VBAT is also removed. I have ran automatic tests overnight where the DVCC and VBAT are both removed, only DVCC is removed etc. and the detection code seems reliable.

On all three of the boards where the RTC was not running, I connected using the MSP-FET Flash Emulation Tool and the IAR IDE using the "connect to running target" feature as well as downloading a new image. With both methods, I was able to see in the registers that the LOCKBAK bit had been cleared by my initialization code so I assume that access to the RTC registers should be open. Additionally, you could write new values to the seconds, minutes, etc.. registers and the new value would be saved and you can read it back. I am initializing the RTCCTL01 register before clearing the LOCKBAK bit on boot up to make sure the RTC is not halted. The RTCHOLD bit was also cleared so the RTC should have been running. If I manually set the RTCHOLD bit in IAR, the seconds, minutes, etc.. registers would return 0 values. When I cleared the RTCHOLD bit they would return to the last written values. This seemed to confirm that the locking mechanisms were working ok.

I also feel that the 32KHz oscillator is running as none of the oscillator fault flags are set and currently I do not have interrupt routines implemented which would clear them (planning to add in the future). I have selected different loading cap values and you can see the frequency shift on the ACLK output through P1.0/ACLK.

The RTCPS0 and RTCPS1 registers never increment either as they would on a board that is working normally. It seems like either the 32KHz signal is not making it to the RTC module or the RTC module is not incrementing for some reason. Is far as I can tell there are no other register settings that would stop it from running are there?

Given the above information, can you think of anything else firmware wise that I should check?

As you mentioned, I am now focusing on the cause of the issue being related to the DVCC and VBAT voltages possibly going above the recommend limits. I wish I had thought to measure the current draw on VBAT while in backup mode to see if a latch-up condition may have been indicated. So far, unfortunately, I have not been able to repeat the issue once I cleared it on the three boards.

We are using a very low quiescent current switching regulator (LT3971) which gives us a good power advantage since we run from non-rechargeable batteries in many cases. The problem is if you turn off the power and then turn it back on quickly before the voltages have dropped - the regulator tends to overshoot the 3.3v. I have seen maximum voltages of about 4.24 volts as you probably saw from the distributer contact. We have and are still adjusting the soft start mechanism to hopefully improve this. Do you have any very low current consumption recommendations to provide clamping of the 3.3 to keep it below the 3.6v limit? Also, do you have any very low quiescent current switching regulator recommendations that may not exhibit this problem?

Thank you very much!
Greg

Greg,

From what you have written above, you said you have not been "able to repeat the issue once it is cleared on the three boards." Does this mean they are "ticking" away correctly now?

As far as additional FW checks are concerned, it seems you are on the right track on this front. May main concern is still the over voltage on VBAT and DVCC lines you get during your testing. Again, situations like this can cause unpredictable results. As far as regulators is concerned, I don't have much knowledge in this earlier for I specialize in MSP. I do know the LM26001 is the TI equivalent to the part you are using. I would check this part out and maybe hop on their E2E forum to see if they have something with a bit more performance that will help out your situation. I'm sure we have something within TI's portfolio, I just can't personally point you to it.

Jace,

You are correct - I originally was given 3 units from our production line where the MSP RTC was NOT "ticking". I went through all kinds of testing and power cycling (DVCC only) and the RTC would not start ticking. I connected with IAR and observed all the registers etc... trying to figure out if anything appeared to be configured wrong but found nothing. On the first 2 units, I finally removed DVCC and VBAT for several seconds, giving caps time to drain, and then repowered everything. The RTC started running just fine after that. On the third unit, I worked more diligently turning the main power (DVCC) on and off - slowly up to very fast. Eventually I noticed that the RTC started running, this time without removing VBAT. That's when I really started looking at the voltages on DVCC and VBAT. I did notice maximum voltage spikes during very fast on/off's of around 4.24 V as I believe you saw in the email.

Every since I got all three units "ticking" again as described above, I have been trying to break them again. So far I have not been able to. I have applied short voltage spikes to DVCC and VBAT using an external power supply through a solid state relay. I started just above 3.3 volts and went all the way up to about 5.0 volts with no issues at all. Once I got to around 5.1 volts, the MSP started having some other issues but once I dropped the voltage spikes back down <= 5 volts, I could see that the RTC was ticking away and normally didn't even loose or gain any time, a second or two at the most. I shorted out the crystal and watched the oscillator fault flags operate as expected. The RTC would of course stop with the crystal shorted, but always started right back up when I removed the short. I can't seem to cause the failure mode to occur again now no matter what I try.

If I am ever able to get the failure mode to happen again, I plan to measure the current draw on the VBAT. That is the one thing that I wish I would have thought to do. I wonder if the RTC module was latched up or something.

Any other suggestions on how I may reproduce the problem? I would love to be able to reproduce it so I can apply a fix and make sure the problem is resolved.

Thank you for the information on the regulators, I will another look at the TI regulator line. The one we are using has a quiescent current of < 5uA. Our total current draw on the board while sleeping is about 70uA. The LM26001 looks like it may be a little higher but I will look at the details. If we can't eliminate the overshoot in all cases we may be forced to change anyway.

Thanks,
Greg