MSP430F5659: gets locked in LPM3, is it an errata?

Hello,

Sorry for the delay but it was holidays here.

We are working on isolating the issue from our code so it's easier to look at (we have a complex device with many peripherals). I'll try to upload it today.

It happens in all cases but debug. My guess is the switching to LPM3 is necessary for it to happen.

When we change the SVSH mode it stops happening, at least in our setup.

Hello

Hopefully I attached a IAR 6.50.1 project that generates at least a particular case of the error.

It looks a lot like a new condition for PMM15. We are still working to find more information.

Please let me know if you can reproduce the error.

Regards

The code consists of a main.c, events.c and timer.h

main.c

The main(void):

performs some initialization (InitPeripherals();) and sets SVSH in automatic, Full/Normal

enables an interrupt for a 32khz timer  (TB0CCTL_bit[TB0_PERIOD].CCIE = true;) - this interrupt will happen every 30.5us as it is reset in the ISR in events.c

then goes into the for(;;) loop where:

sets Watchdog

sets a timer with the SMCLK (TA0CCR[TA0_GEN] = TA0R + i;) with a variable duration (depends on i)

waits for the timer 

goes to LPM3 tracing the time in this mode on P5.7, the interrupt on background should wake it up

Test MSP430F5659 20170307 1300.zip

Agustin,

I looked over your code and found some things I wanted to discuss with you.

In "main.c" file, inside the main function you enter LPM3.

The line of code you use is,

__low_power_mode_3();

which is defined in instrinsics.h. This macro is,

#define __low_power_mode_3()                    \
  (__bis_SR_register(  __SR_GIE                 \
                     | __SR_CPU_OFF             \
                     | __SR_SCG0                \
                     | __SR_SCG1))

Which brings us to "events.c". In this file you use the function:

__LPM_off_on_exit();

You #define this function as,

#define __LPM_off_on_exit() __bic_SR_register_on_exit(__SR_CPU_OFF | __SR_SCG1 | __SR_OSC_OFF)

This is not consistent with the function you need to exit LPM3 mode. You are using _SR_OSC_OFF which is not needed and you are not using _SR_SCG0.

The correct function to exit LPM3 is:

__bic_SR_register_on_exit(  __SR_CPU_OFF     \
                             | __SR_SCG0        \
                             | __SR_SCG1)

The following macros are already provided and can be used to avoid the issues above.

/* Low Power Modes coded with Bits 4-7 in SR */

#define LPM0_bits           (CPUOFF)
#define LPM1_bits           (SCG0+CPUOFF)
#define LPM2_bits           (SCG1+CPUOFF)
#define LPM3_bits           (SCG1+SCG0+CPUOFF)
#define LPM4_bits           (SCG1+SCG0+OSCOFF+CPUOFF)


#define LPM0      __bis_SR_register(LPM0_bits)     /* Enter Low Power Mode 0 */
#define LPM0_EXIT __bic_SR_register_on_exit(LPM0_bits) /* Exit Low Power Mode 0 */
#define LPM1      __bis_SR_register(LPM1_bits)     /* Enter Low Power Mode 1 */
#define LPM1_EXIT __bic_SR_register_on_exit(LPM1_bits) /* Exit Low Power Mode 1 */
#define LPM2      __bis_SR_register(LPM2_bits)     /* Enter Low Power Mode 2 */
#define LPM2_EXIT __bic_SR_register_on_exit(LPM2_bits) /* Exit Low Power Mode 2 */
#define LPM3      __bis_SR_register(LPM3_bits)     /* Enter Low Power Mode 3 */
#define LPM3_EXIT __bic_SR_register_on_exit(LPM3_bits) /* Exit Low Power Mode 3 */
#define LPM4      __bis_SR_register(LPM4_bits)     /* Enter Low Power Mode 4 */
#define LPM4_EXIT __bic_SR_register_on_exit(LPM4_bits) /* Exit Low Power Mode 4 */

So all you would have to do is use LMP3; to enter LPM3 mode and LPM3_EXIT; to exit it.

Also if you would like to enter low power modes with interrupts enabled, as shown in the User Guide for MSP430x5xx and MSP430x6xx on page 67.

// Enter LPM0 Example
__bis_SR_register(LPM0_bits + GIE); // Enter LPM0 with interrupts enabled
// Exit LPM0 Interrupt Service Routine
__bic_SR_register_on_exit (LPM0_bits); // Exit LPM0
// Enter LPM1 Example
__bis_SR_register(LPM1_bits + GIE); // Enter LPM1 with interrupts enabled
// Exit LPM1 Interrupt Service Routine
__bic_SR_register_on_exit (LPM1_bits); // Exit LPM1
// Enter LPM2 Example
__bis_SR_register(LPM2_bits + GIE); // Enter LPM2 with interrupts enabled
// Exit LPM2 Interrupt Service Routine
__bic_SR_register_on_exit (LPM2_bits); // Exit LPM2
// Enter LPM3 Example
__bis_SR_register(LPM3_bits + GIE); // Enter LPM3 with interrupts enabled
// Exit LPM3 Interrupt Service Routine
__bic_SR_register_on_exit (LPM3_bits); // Exit LPM3
// Enter LPM4 Example
__bis_SR_register(LPM4_bits + GIE); // Enter LPM4 with interrupts enabled
// Exit LPM4 Interrupt Service Routine
__bic_SR_register_on_exit (LPM4_bits); // Exit LPM4

Please let us know if this solves the issue.

Well not clearing the SCG0 means that technically speaking you are not exiting LPM3, based on the definitions of LPM modes and Active mode.

Not clearing this bit means keeping the FLL disabled which as described in the User Guide page 167,

"When the FLL operation is disabled, the DCO continues to operate at the current settings. Because it is not stabilized by the FLL, temperature and voltage variations influence the frequency of operation. See the device-specific data sheet for voltage and temperature coefficients to ensure reliable operation."

I am testing the code. You mentioned the issue you are facing doesn't show up in debug mode?

Agustine,

I have tested your code and modified somethings to figure out what was causing the problem.

The first thing I did was add,

P6OUT_bit.P6OUT4 = 1;
__delay_cycles(2000000);
P6OUT_bit.P6OUT4 = 0;

to the main function before the for(;;).

This helped me use an LED to detect whether the watch dog timer was able to reset the device when we would get stuck or not.

Every time I would see the code stop working it would take approximately 16 seconds for the watch dog timer to reset the device.

Next I verified the TimerB interrupt. I commented out the lines of code inside the for(;;) loop related to TimerA to make sure that we could go into low power mode and exit out of it every 30 us. This also worked.

Finally I tested the two timers together. The original code gave TimerA a period of 60 ticks to 80 ticks. At 4 MHz input clock, this would take 15 to 20 us for TimerA to time out.

The first thing I tried was trying the code with a constant period of 60 ticks. This worked. So I ran the test multiple times to see what TimerA period would cause the code to stop exiting LPM3 mode. The value I reached was 68 ticks as the period of TimerA.

I am currently suspecting that it could be the errata PMM15. If the time between timer setup to timer timeout is close to 30 us, it could be what PMM15 has stated. 

Agustun,

I just double checked with the scope and the TimerA timeout on scope shows more than 28 us with i = 70. 29 us is the max that would be allowed based on PMM15. However, you are correct about the SVSH setting. I will look into whether this is a new condition or a different issue. For now there are two options,

1. Use TimerA with values less than 70 (67 to be exact).

or

2. Use TimerB with longer timeout. I used 50 us as an example and the issue is not seen anymore.

If this solves the issue please click Verify Answer

The issue appeared in a new device that uses TimerB and an asynchronous input, so changing or limiting the Time will not work. We really need to know if it's a new errata or new conditions and in either case which conditions, so we can use a workaround or avoid the errata.

Hi Agustin,

Which device revision are you using?

Hello Cameron,

We initially saw this behavior on:
MSP430F5659 (ZQW package)

We then reproduced it on:
MSP430F5659 (PZ package)
MSP430F6659
MSP430F5342 
 
The markings are listed below. I couldn't find how to identify the revision from them.

46AG35TG4
MSP430F5659

MSP430F5342
TI 571 K
AXLO G4

MSP430 TM
F6659
2BC41PT A
TI G1

MSP430F5659
62AP5LTB
TI G1

Regards,
Agustin

Hello,

Were you able to find more information about this??

Regards,

Agustin

Agustin,

I was able to recreate this issue on the MSP430F6659 also. You mentioned that the SVS in manual mode eliminated this error? I would like to next test different SVS modes.

Could you please share what you changed in your code to cause this issue to be eliminated?

Agustin,

Just wanted to check in and let you know we are still working on this and I will get back to you as soon as we find an answer.

Thank you for your patience.

Thanks,
Meanwhile we are disabling the automatic change of the SVSH. That seems to avoid the issue.
Let me know if you make any progress.
Regards