This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Data loss in info memory after power cycle

Other Parts Discussed in Thread: MSP430F2252, MSP430G2553

Hi,

We have an interesting but troubling situation.  MSP430 is used to control a small motor.  Normally we keep track of any settings in RAM.  But when power is lost, those settings are stored in the info memory.  At powerup, we recover the data and continue operation, as if power was ok.  The board has circuitry to indicate the ShutDown (at P2.4 of the micro) and provide sufficient power to allow for a write operation to flash.  We're using MSP430F2252 micro, running at 8MHz and 3.3V.  The voltage is sustained and stable for at least 600ms after ShutDown is triggered, which generates an interrupt.  The ISR halts all operations and proceeds to save the data.

Most of the time, this scheme works.  However, occasionally, when power is switched on, the settings are not properly restored, so the algorithm loads default values.  My investigation so far shows that when the memory is read back, it is blank, as if it was never programmed, or it was erased, at some point, before being read.  Needless to say, that a normal erase function is always called after data is recovered.  Again, most of the time, the system works fine.  The probability of this error is much less than one percent.

Has anyone else seen such behavior?  Any ideas what could go wrong or what could cause this?  Any conditions that could make the flash vulnerable?

Here's some of my initialization code:

 BCSCTL1 = XTS + DIVA_1 + XT2OFF + 0x0D;
 DCOCTL = DCO2;                                                   //internal oscilator, just in case
 BCSCTL2 = SELM_3+SELS;                                 //switch to the crystal, main clock 8 MHz
 BCSCTL3 = LFXT1S1 + XT2S1;                            //switch to the crystal, main clock 8 MHz
 IFG1 &= ~OFIFG;

 FCTL1 = FWKEY+WRT;
 FCTL2 = FWKEY + FSSEL_0 + FN4 + FN2;
 FCTL3 = FWKEY+LOCK;

I'm still troubleshooting this, and will post any relevant updates.  Currently, I'm suspecting it may be related to another, perhaps more serious flash related issue I found, while testing this one.  (I'll post that one separately.)

  • I don't know the 2252 from own experience (and out fileserver is currently down, so I don't have access to the datasheets and I'm too lazy to search the TI site for them)

    Anyway, your init code looks a bitt different than mine on the 1611 (which has similar/same flash controller).

    your code excerpt does not really say what you're doing.

    the general flow should be:

    DINT(); // no interrupts allowed, but NMI cannot be masked, so disable all possibly enabled NMI sources too. Interrupts during a write operation will crash the MSP.
    FCTL2 = FWKEY|FSSEL_0|FN4|FN2;  // if this is correct...
    FCTL3=FWKEY;
    FCTL1=FWKEY|WRT;  // or erase or whatever
    // do the write here, either data writes (WRT) or  dummy write (ERASE)
    FCTL1=FWKEY; // clear the write mode bits)
    FCTL3=FWKEY|LOCK;
    EINT();

    Even if your writing function runs undisturbed, there are some conditions where it might fail:
    Power fails, data is written, power is restored, data is read and erased, but then power fails again, while the backup hadn't time to recharge. 'bouncing' is a common process, not only with data lines.
    Try to wait a sufficient time after power-up before you erase the data. Remember, flash operations (especially erase) require a high current, so this current may cause a sudden power-fail during flashwrite activity. Also, the minimum flash voltage (with these 5mA) is higher than the minimum MSP operating voltage.

    I regularly write data too in my projects (not only on power-fail). I use double-buffering. There are two stored configurations, both with CRC. When starting, I read both and do a CRC check. And I use the first I find. The configuration contains the info where it comes from (1st or 2nd config copy). If I write, I erase the info segment containing the other copy (from which I did not read last time), then change the 'from' bit, recalculate the CRC and write the config. If power fails during write, the other copy is still untouched and will be loaded again. When the write is successful, I invalidate the other copy by overwriting the CRC with 0x0000. I could erase the segment instead, but this takes much longer, requires more possible precious power and on next write, I will erase it anyway, as I cannot be sure whether it was properly erased last time.
    Due to the cleared CRC, this config won't be accepted as valid on next startup.

  • Hello ArmenG,

    i am using MSP430G2553 for my application for a 3-phase voltmeter. i am also facing the same problem of loosing the flash content.

    is your problem solved by this solution of disabling all the intterupts at the time of flash writing. If so, then can u please tell me the functuion for disabling the interrupts.

    if possible, please reply fast.

    Thank you,

    Saurabh bansal

  • __disable_interrupt(), and __enable_interrupt(); (basically clear and set the GIE bit in the status register).

    However, NMIs cannot be disabled globally, here you'll need to clear the respective IE bits -  if you set them before (there is no NMI interrupt source activ eby default)

**Attention** This is a public forum