• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 354 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430G2553: Flash memory corruption during power cycling - GAH!

Andrew DeWeerd
Prodigy 100 points
Part Number: MSP430G2553
Other Parts Discussed in Thread: MSP-FET

This happens intermittently - some devices do it consistently, others never do it.

Most of the time, INFO B area (0x1080) is erased (0xFF's).  See image #1 below.  The memory corruption always happens during power cycling.  

Today, one of the devices stopped working altogether.  I examined its memory and was shocked to find that some of the code flash memory was corrupted - looks like it was written with mostly zeros.  I was repeatedly replacing the battery when it happened.  In this case, the bits were written (0's). 

The device is battery powered.  I do have flash erase and write routines, but they are only called during uart activity that requires checksums etc, and none of that is happening here.  I'm guessing that the stack pointer is going nuts on powerup (or down) and executing some of that flash code, but that's just a guess.  The code was originally written to the processor with an MSP-FET debugger.

Thoughts?  

  • 0
    Prodigy 100 points

    BTW, there is no voltage supervisor on the reset.  I'm gonna kludge one on there to see if that fixes the issue, then redesign board if it does.  

  • 0 in reply to Andrew DeWeerd
    TI__Guru 56685 points

    Hello Andrew,

    Please check out the following application note to help you debug this flash corruption issue. 

    Debugging Flash Issues n MSP430 MCUs 

    More than likely, if the issue is happening on a power drain of the battery, the voltage slips below the minimum needed for the frequency you are operating at, causing unexpected execution. When paired with flash write routines and slow ramp down, you can get flash corruption like this. An external SVS would ensure the device stays in Reset during these power zones, thus preventing unexpected execution. 

  • 0 in reply to Jace H
    Prodigy 100 points

    That link didn't work.  But your answer gave me an idea.  There is a lot of capacitance on the processor supply, so when the battery is removed the powerdown is probably slow.  Perhaps I can detect the battery being removed and enable a load to increase the slew rate of the supply.  

    Although the SVS is going to be added, I've got thousands of these on the shelf right now.  That's my immediate concern.  

  • 0 in reply to Andrew DeWeerd
    TI__Guru 56685 points

    Sorry about that, link should be good now. 

**Attention** This is a public forum