• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 673 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.

MSP430F2112: Possible Failure Caused by Segment A Erase

Kenichiro
Mastermind 9165 points
Part Number: MSP430F2112

[ MSP430F2112 ] Possible Failure Caused by Segment A Erase

Hi,

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?

Thanks,
Ken

<Related Post>:

MSP430F2112: BCM initialization: Setting fCPU=16MHz
e2e.ti.com/.../662987

  • 0
    TI__Mastermind 49692 points
    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.

    Regards,

    James

    MSP Customer Applications
  • 0 in reply to James Evans
    Guru 46710 points

    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.

  • 0 in reply to Ilmars
    Mastermind 9165 points

    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!

    Thanks,
    Ken

**Attention** This is a public forum