Due to the U.S. Thanksgiving holiday, please expect delayed responses during the week of 11/22.

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.

MSP430F2112: Possible Failure Caused by Segment A Erase

Part Number: MSP430F2112

[ MSP430F2112 ] Possible Failure Caused by Segment A Erase


Can you help my customer to debug their issue found on their own board with MSP430F2112?
My customer has reported that MSP430 shows unstable operation and malfunction.

From discussion with customer, we have found that the Segment A is erased, all FFs.

As our understanding, if Segment A is erased, the processor frequency cannot be set correctly, and let MSP430 run under out of range eventually.

Also, we have received some failure units from customer and performed curve trace analysis.
The result shows that failure units have slightly different V/I characteristics on pin 7 (RST/NMI/SBWTDIO) compare with known good device.

Do you think Segment A erase cause this kind of failure?


<Related Post>:

MSP430F2112: BCM initialization: Setting fCPU=16MHz

  • Hello Kenichiro,

    I wouldn't be surprised by this behavior, since the calibration data is stored for both the DCO and for ADC10 organized in a tag-length-value (TLV) structure. Personally, I've never measured this and would be more concerned by what's causing Segment A to get erased. Are they writing to this Segment frequently? Perhaps, they are preparing to write to the Segment, back it up in RAM, and before writing everything back, the device gets reset causing the TLV values in RAM to be lost and the Segment to stay erased. Obviously, the fewer times this Segment is modified the better.

    Besides what could be erasing the Segment, I would also carefully make sure that the JTAG interface matches our recommendations and that all capacitances are what we recommend in the datasheet.



    MSP Customer Applications
  • This is firmware problem. Most likely cause of flash corruption is 1) presence of flash manipulation code in firmware combined with 2) CPU frequency manipulation. Many msp430 users who want higher than 1MHz CPU frequencies, do not ensure that VCC is reached safe voltage to operate at high frequency such as 16MHz. They happen to configure DCO right after brownout release (~1.1V or so) and CPU obviously crashes doing unexpected things .

    It is solved by introducing startup delay using __delay__cycles() for time which is at twice as power supply rise time. Other option is to introduce external voltage supervisor which releases CPU reset only when supply is at 3.3V.

  • Hi James, Ilmars,

    It's really helpful for me, caz I'm not EP-man : (
    Thank you for your support, I will consult with my customer together with EP FAE in my team!