LOCKBAK getting set again after being cleared on a MSP430F5636

Hi,

I see from your post here:

Devon St. Pierre said:

What I'm finding is that when I run with the debugger connected,  that LOCKBAK is cleared in my start up code and stays cleared.  As a result I am able to read and write the RTC registers successfully.  I've written a command in my firmware that allows me to see that LOCKBAK is cleared:

>get -y
SYSRSTIV: 0000
BAKCTL : c000
RTCCTL01: 3005

Now on the other hand, if I run with the debugger disconnected I can see that LOCKBAK doesn't stay cleared, (not to mention that I can't read or write the RTC registers):

>get -y
SYSRSTIV: 000e
BAKCTL : c001
RTCCTL01: 3001

SYSRSTIV in your failing case appears to be set to 0x0E. Looking in the MSP430F5636 datasheet Table 13 System Module Interrupt Vector Registers, you can see that this corresponds to SVSH causing a reset. This would indicate that something is causing the SVSH to trigger a reset, and this would also then be causing LOCKBAK to get set. It seems like something might be causing your part to reset. I'd recommend adding a pin toggle or something at the top of your code so that you can track or log every time your device resets using a scope or some other tool. I'd also recommend looking at your DVcc the whole time you are running and see if there are any potential dips etc (for example, if your design draws a lot of current at some point during operation it may have a dip in voltage). Also do you ever adjust the Vcore setting (perhaps so you can run at a higher frequency?) this would involve touching the PMM/SVS modules.

-Katie

Katie,

Thanks for your reply... Yes, switching from the case with the debugger connect to the case where I was running stand alone, I turned off the power.  Powering up stand alone and issuing my get -y command reported a SVSH causing the power outage.  I've also seen 0x0C (SVSL) cause the outage as well making the switch.  My start up code clears LOCKBAK like this:

while(BAKCTL & LOCKBAK)         
       BAKCTL &= ~(LOCKBAK);

Note the LOCKBAK must be clear at some point for me to leave the while loop.  Then I issue my get -y command and see that LOCKBAK is set again:

>get -y
SYSRSTIV: 000e
BAKCTL : c001
RTCCTL01: 3001

I have another command (set -z) that I issue than runs the code to clear LOCKBAK again:

while(BAKCTL & LOCKBAK)         
       BAKCTL &= ~(LOCKBAK);

Then I check the status of LOCKBAK again:

>get -y
SYSRSTIV: 0000
BAKCTL : c001
RTCCTL01: 3005

LOCKBAK is set again.  Its interesting to note that SYSRSTIV doesn't show anything.  It must be cleared when its read?  Note also that there is a reserved bit set in RTCCTL01.  I'm not sure what that indicates.

My code prints out a header and a new prompt each time it starts so I'm pretty sure that my firmware is not restarting.  I will double check toggling a pin and checking with a scope as you suggest.

I've previously checked my Vcc with a scope and have not noticed any dips.  Wouldn't it have to dip down to like 1.64 volts for SVSH or SVMH to reset the processor?

I did think to comment out my call to change the Vcore setting until after I get this problem with LOCKBAK figured out.

Again in summary LOCKBAK sets as I would expect after I power off my device.  I can clear it in my start up code when I re-apply power (and also with my set -z command that runs the code to clear LOCKBAK at run time).  But after clearing it each time, it sets again and I'm not seeing any indication that I'm losing power to cause a reset.

Something is causing LOCKBAK to set that I'm not understanding.

I'll do some more checking on my end and let you know what I find.

thanks...

LOCKBAK is not only set on a power loss. It is also set if the SVS detects a voltage drop and switches to backup. So if you have an instable supply, LOCKBAK can be set regularly, even if the device never resets. You may set-up the SVS to make the switch at a lower voltage (so the dip is not detected) or trigger an interrupt, so you can clear LOCKBAK inside the ISR.

Greetings... I've done some more checking and am still not getting to the bottom of this.  I've put a scope on my Vcc and set it up to trigger if the voltage ever drops below 2.96 volts and it never triggers.  Mean while I can see with my get -y command that the LOCKBAK bit continues to be set.  I can clear it with my set -z command.  I've instrumented some code that measures that amount of between when I clear the bit with my set -z command and when I detect that it is set again.  It takes less than a second to set and is very repeatable.  

I also noticed the following for what ever its worth... I've added some code to read SYSRSTIV three times when I power up stand alone:

void main(void)
{           

    WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
    SysRstIv = SYSRSTIV;
    SysRstIv2 = SYSRSTIV;
    SysRstIv3 = SYSRSTIV;
...

Then when I display the three reading later I see the value changes each time it is read:

I still haven't figured out why LOCKBAK is continuing to be set, but I did verify that when running off main power (Vcc) that no current is drawn from the backup battery (VBAT) even when LOCKBAK is set.

If I need to access RTC registers, I clear LOCKBAK and I'm able to access them before LOCKBAK sets again.

Thanks for the reply... I had not seen the guidelines on Running RTC with Battery Backup Module.  Its a nice write up that I wish I would have found when I first started into this.  Reading over it, there isn't anything that I haven't tried.  As I mentioned previously, I've verified that no current is drawn from the backup battery despite the fact that LOCKBAK continues to be asserted.

No, I'm not using MSP430 Ware.

Thanks...

One more possibility, which I assume you are doing based on the thread:

The LOCKBAK bit has to be cleared because the LFXT is part of the backup domain and "LOCKBAK is always set to 1 by hardware after the core was powered down either due to a complete power cycle of the main supply DVCC or due to LPMx.5 operation.

I second your consideration that the SVS should by default only trigger on below 1.69V. Well, when using library code to raise PMMCOREV for >8MHz operation, this may also change the SVS trigger levels. Still, your 2.96V should be sufficient in any case.

With ‘with debugger attached’, you mean the FET is plugged but no debug software running? OR is the debugger software running? IN this case, the debugger may have overridden some things.
Also, with ‘set to 0V’ do you mean you have wired the FET so it attaches itself to the current system voltage (VSense pin connected to VCC, and VCC_out disconnected) or do you have the VCC_out connected and just set the voltage setting to 0V? In the second case, the backflow form VCC to the FET may influence your supply, like adding additional capacitance and stabilization as well as additional load to it.

Thanks for the reply... I've been careful to comment out the calls to library functions to change the PMM Core voltage.

"with debugger attached"  I mean its connected and running debugger software.  I must have VCC_out connected and have set the voltage setting in CrossStudio to 0 volts.  So as you indicated there must be something going on when the debugger is attached that adds capacitance or somehow stabilizes things.

When measuring Vcc I was probing on the power pin of another (larger footprint) IC on my board. So I wasn't on the MSP's power pins or at the supply.  I have verified that we have Vcc connected to all three power pins on the MSP430 and each has its own blocking cap.

As I mentioned early. I've verified that when my main power (Vcc) is supplied there is no current drawn on the VBAT pin even when LOCKBAK is set.  I can clear LOCKBAK in my firmware and the MSP430  just sets it again.

IIRC, the supply is switched back to VCC as soon as VCC is considered sufficient again, while LOCKBAK remains set. However, I fear this problem I beyond what could be done using remote support.
There is the possibility of hair cracks on the supply traces or bad soldering of one of the MSPs power pins, so sudden changes in the operating current cause internal voltage dips. However, this is plain guessing. To be of any more help, I think I would need the device on my desk. Sorry.

I have been able to get the following recommendation:

What would I try at first is lowering the SVS High side trigger to its lowest setting and seeing if that is still triggering the switchover. It is curious that the problem goes away while the debugger is connected. Try to reproduce the error with the debugger connected, and have it run in “Free Run” mode so no debug software is running. If no problem is apparent with this, then the debugging is helping to stabilize VCC/GND here. With all the focus on VCC stability, I wonder how stable the GND plane is.

Tim Chao Li said:

I wonder how stable the GND plane is.

Indeed, GND ripple due to operating currents can also be an issue. That’s why I asked where the ‘stable’ supply was measured. Important is the voltage across the MSP’s power pins. All of them, if routed separately. Not just VCC against the supply GND point or such.