We are using CC430F5137. We are seeing the processor reset when we come out of LPM3 on an interrupt triggered by a falling edge on a pin. We don't see this when it's connected to the debugger. We noticed the debugger appears to hold the TEST line high. We put a 10k pull-up on this line, and it prevents the unwanted resets.
Do you know effects the pullup may be having that may prevent the resets?
Is there a reason not to pull it high in a design?
We thought erratum PPM11 from the CC430F512x Errata document looked promising, but the workaround did not work for us.
Do you have any thoughts on the next debug step to find the cause of these resets?
Thanks!!
CJ
Charles GervasiDo you know effects the pullup may be having that may prevent the resets?
2.2.8.1 Wakeup Times in Debug Mode The TEST/SWBTCK pin is used for interfacing to the development tools via Spy-Bi-Wire and JTAG. When the TEST/SBWTCK pin is high, wakeup times from LPM2, LPM3, and LPM4 may be different compared to when TEST/SBWTCK is low. When the TEST/SBWTCK pin is high, all delays associated with the SVSL and SVML settings have no effect and the device will wakeup within tWAKE-UP-FAST . Pay careful attention to the real-time behavior when exiting from LPM2, LPM3, and LPM4 with the device connected to a development tool (e.g. - MSP-FETU430IF).
The TEST/SWBTCK pin is used for interfacing to the development tools via Spy-Bi-Wire and JTAG. When the TEST/SBWTCK pin is high, wakeup times from LPM2, LPM3, and LPM4 may be different compared to when TEST/SBWTCK is low. When the TEST/SBWTCK pin is high, all delays associated with the SVSL and SVML settings have no effect and the device will wakeup within tWAKE-UP-FAST . Pay careful attention to the real-time behavior when exiting from LPM2, LPM3, and LPM4 with the device connected to a development tool (e.g. - MSP-FETU430IF).
Charles GervasiDo you have any thoughts on the next debug step to find the cause of these resets?
Is it possible to determine the value of SYSRSTIV register after an unwanted reset, to determine the cause of the reset? (although without a debugger attached this is difficult as you have to output the value of the SYSRSTIV register somehow)
We have found this problem only occurs if we have the RTC enabled. If RTC is enabled and TEST/SBWTCK is not pulled up, it will reset when it wakes up from LPM3 on a hardware interrupt. So we can simply not use the RTC. Is there any app note on how to use RTC with LPM3 without having this problem?
I had an example for a CC430F5137 which uses a RTC with LPM3 which ran OK when the debugger (an Olimex MSP430-JTAG-TINY-V2) was attached.
With the debugger removed it won't run unless I pull TEST high. i.e. appear to have repeated your problem. Will try and work out the cause of the failure.
A software engineer wrote code to bit bang out the value of the reset register and it show the reason for reset as brownout. He disabled the brownout detection, and it still happens. We suspect some kind of bug within the chip.
Hi Charles,
Three things came to my mind to nail this down.
- Have you monitored MCLK (via pin output) at LPM exit? This would allow you to 'see' PMM11' effect: The frequency would be too high. (single shot on first edge)
- Have you monitored AVCC and DVCC while this issue happens?
- What are you voltage levels, MCLK frequency and VCore settings?
You don't want to pull the TEST pin high as pointed out already by Chester, as this influences power and timing.
Regards, Dietmar
Dietmar Schneider - Have you monitored MCLK (via pin output) at LPM exit? This would allow you to 'see' PMM11' effect: The frequency would be too high. (single shot on first edge)
Yes. We tried the PMM11 workaround to no effect.
Dietmar Schneider Have you monitored AVCC and DVCC while this issue happens?
Have you monitored AVCC and DVCC while this issue happens?
We could not detect any sag.
Dietmar Schneider - What are you voltage levels, MCLK frequency and VCore settings?
We have tried several settings. We're running it at 3.0V most of the time for these tests. MCLK frequency is always well within the limits of the core setting. We tried tinkering with these a lot.
The problem happens when an interrupt occurs during LPM2 or LPM3. We do not believe any sort of bona fide brownout is taking place.
The software engineers are just avoiding using RTC, which prevents the problem. If that becomes onerous, they'll create a simple program that demonstrates this on an eval board. They've determined the same thing happens on the eval board.
Charles GervasiYes. We tried the PMM11 workaround to no effect.
Does this mean your frequency is as expected or too high?
Charles GervasiIf that becomes onerous, they'll create a simple program that demonstrates this on an eval board. They've determined the same thing happens on the eval board.
This would help a lot. Recreating it at my bench here would allow me to support you best.
Charles GervasiIf RTC is enabled and TEST/SBWTCK is not pulled up, it will reset when it wakes up from LPM3 on a hardware interrupt.
YOu cannto disable the brownout detection. You can enable and disable the SVS, but not the basic BOR circuit. And disablign it won't make any sense since it detects a voltage drop below the minimum voltage requirements, so a BOR would have crashed the processor anyway.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Jens-Michael Gross You cannot disable the brownout detection. You can enable and disable the SVS, but not the basic BOR circuit. And disablign it won't make any sense since it detects a voltage drop below the minimum voltage requirements, so a BOR would have crashed the processor anyway.
You cannot disable the brownout detection. You can enable and disable the SVS, but not the basic BOR circuit. And disablign it won't make any sense since it detects a voltage drop below the minimum voltage requirements, so a BOR would have crashed the processor anyway.
We attempted to disable it because we believed the brownout was bogus. The problem happens on our board (which I believe is well decoupled) and the eval board. Disabling RTC makes the problem go away. Enabling RTC causes a reset every time.
Hi Chester / Charles,
Can you provide a small test program that causes this behavior? I would like to recreate at my desk to support you.
Dietmar,
I am unable to provide a test program that causes this behavior.
It turns out that my problems were a combination of:
a) A I2C slave which sometimes failed to ACK the first transfer after a power-up
b) A MSP430ware driverlib bug - Error in watchdog timer reset function in build 1.10.00.18 of MSP430ware
Thanks for the feedback Chester. The 430ware team is looking into the issue with the reset function.
hello everyone, even I have noticed similar problem when I am coming out of the lpm3 ... the uC resets.. however, i m using msp430f2xx series...
also, i do not observe the reset happening when I am using debugger to run the code, so, I am really confused how to solve this issue... problem occurs only when the uC is running in real time mode w/o JTAG connector... I do not have any pull ups or pull down resistors on the JTAG ports...
MSP430 Kors hello everyone, even I have noticed similar problem when I am coming out of the lpm3 ... the uC resets.. however, i m using msp430f2xx series...
I am told the problem we were having had to do with PMM settings when the radio was set to receive during LPM3. If you're using the radio, I can probably find out which register settings they changed.
no, i am not using any radio... all i am doing is writing to internal flash memory and then coming out of the LPM... it is after the writing to internal flash mem, reset occurs... and it occurs always at the same location...