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.

MSP430F249: Data corruption occurred when Flash memory was repeatedly powered on and off

Expert 2125 points
Part Number: MSP430F249

I have questions about Flash memory in MSP430F249.

1.Is there a possibility that data in flash memory will be destroyed by repeated power ON/OFF cycles?

2. What is the type of flash memory in MSP430F249, "NAND type" or "NAND type"?

3.In the 3.2 Flash Endurance chapter of the URL, there is a statement that Flash endurance is 10000 cycles.

 Do you have information on the cause and probability of occurrence when data is destroyed by reading or writing flash memory?

4.When writing data to Flash memory, is it necessary to take measures against bad blocks (bad sectors) in Flash memory?


[Background of the question]

The phenomenon of data corruption occurred when MSP430's Flash memory was repeatedly powered on and off.

Flash memory control register (FCTL2) is set to 400 kHz.

It is set to information memory segment B (start address 0x1080), and word write was performed.

Of the total size of segment B of 64 bytes, 38 bytes are used.



  • Hi Koki,

    The most likely cause is VCC drops below the specified operating voltage during the time code is writing to FLASH memory.

    Here is a document (SLAA729A) that has helpful information regarding troubleshooting FLASH memory issues.

    Does power cycling damaging the FLASH -  no.

    You are correct about the erase/write endurance.  If your application will potentially exceed this level, you might consider switching to an MSP430 FRAM device.  FRAM devices essentially have no endurance limitation.

    And all other FLASH-related questions should be answered in this document (SLAA344B), which describes the TI FLASH memory.

    The MSP430F249 has an internal comparator that can be used to monitor the VCC voltage. Have you considered using it to notify when the VCC has dropped below the normal operating level and avoid writing to FLASH during this time?

  • Hi, Dennis

    Thank you for your quickly answer.


    >Have you considered using it to notify when the VCC has dropped below the normal operating level?

     When writing, the reset circuit handles the resetting at 2.7V or lower by implementing a reset circuit.


    I checked the two documents, but there was no mention of whether TI's microcontroller is a NAND or NOR type.

    I also could not find the following two pieces of information.

    >Do you have any information on the cause and probability of occurrence when data is destroyed by reading or writing flash memory?

    >When writing data to Flash memory, is it necessary to take measures against bad blocks (bad sectors) in Flash memory?

    If you have any information about that, please let me know.



  • Hi Koki,

    It would be a NOR FLASH.

    Regarding the cause and probability of occurrences, document SLAA526 is the only available document that covers this information.

    The only other document that might be helpful is document SLAA392.

    There are techniques, such as using a CRC and write 2 separate copies of the data.

  • Hi, Dennis

    I am writing to Flash memory according to the procedure in User guide.

    Do I need to take any action against Bad Blocks?


  • Hello Koki,

    There is a section on memory protection in the MSP430 FRAM Technology - best practices guide.

  • Part Number: MSP430F249


    The flash memory values of MSP430F249 are destroyed by repeatedly turning the power on and off.


    - The power is turned on and off repeatedly at 1-second intervals.

    - The SUM value is written in the memory. Calculates the SUM value when the device is powered on. If it does not match the written SUM value, an error occurs.

    - If an error occurs, the contents of the memory data are checked in CCS. Memory corruption has occurred on multiple devices, and the damaged memory values are different for each device.
      (The phenomenon was confirmed on 8 out of 100 devices)

    - I rewrote the device that had the memory corruption and it was able to write normally.


    If you have any ideas for investigating the cause, please let me know.



  • Hello,

    If you're trying to write to Flash during a power failure, then memory corruption is definitely possible if it's not finished before the supply voltage drops below the minimum voltage for programming the Flash.

  • Hi,

    It is designed to be reset at 2.7V so that it does not fall below the operating limit voltage of the CPU.

    Please let me know if you have any other concerns or information you would like to know.

  • Does the reset wait for the Flash write to complete? Also, I see that you've posted your question twice. In the future, please make only one post per question. I'm merging your threads.

  • Hi,

    There is additional content I would like to hear.

    Is there a possibility that the operation of turning the power on and off while reading Flash may lead to the destruction of the Flash memory value?

    Also, please let us know if there are any related documents regarding the above information.

  • Hi Koki,

    I reviewed your issue with one of our experts and they conclude it is up to the application or your design to ensure that the MCU is operating within the specified VDD operating voltage range while performing any flash modifications. Operating outside this range, TI cannot guarantee the integrity of the data written into FLASH memory.

    You can do a few things, as mentioned before, such as using the comp_A comparator in the MSP430F249 to monitor the VCC voltage and generate an interrupt if the voltage falls below, say 3.0v.  This is used to notify the CPU that the VDD is crashing and all writes to FLASH should be aborted.  Relying on the internal voltage supervisor to generate a reset is not a solution. 

    Along with this, increasing the bulk capacitance on or near the MCU's VDD pins (adding a larger capacitor, 10uF example) will help by extending the time it takes for VDD to collapse, but won't solve the underlying issue.  When used with the aforementioned comparator scheme, this will extend the FLASH write time.  Note, you will need to confirm, either through simulation or bench test, including temperature variations, that as the voltage drops from say 3.3 down to 2.7v,  the added capacitance provides enough of a delay allow the FLASH write operation to be completed.  Don't forget to add some margin as well.

    Example, operating at 3.3v,  if the comparator triggers when there is a 10% drop in VDD, or at 3.0v, and if  it takes 1ms to perform the write operations to FLASH, you need to ensure that the time it takes for VDD to go from 3.0v down to 2.7v is at least 2x the time you need to complete the write operation, or 2ms.

    If you need help determining these parameters, let me know.

    Until then, there isn't much else I can suggest or recommend.

  • Hi Koki,

    It's been a few days since I have heard from you so I’m assuming your question has been answered.
    If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
    If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.