• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 164 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.

MSP430F133: Part appears to be issuing a Mass-Erase operation for no good reason after deployment in field

Rod Martinez
Prodigy 80 points
Part Number: MSP430F133

We use the MSP430F133 device in a control handle for our machines.  A few years ago, we had several instances of these handles becoming non-functional.  Upon analysis, I found that the MSP430F133 controllers in them were completely blank, as if a Mass Erase operation had been performed.  At the time, after looking into the issue and with help from TI, surmised that noise was possibly getting into the JTAG connection, and initiating an operation with a bad code-protection password.  This causes the BSL to do a Mass-Erase.   So, I installed an RC filter on the TCK pin, and the problems went away.  The newer datasheets recommend a similar filter on the TDI pin as well, which I had not implemented.

Now, we have a new rash of failures, with the chips coming back completely blank.  I believe that this may be due to Vcc instability, as we had a beta setup in a batch of these machines that could cause severe VCC oscillations that this chip would have to endure.  However, it's worth noting that there is NO FLASH writing that goes on in our firmware, and from what I gather in these forums is that FLASH erasure or corruption is impossible due to merely having an unstable Vcc.  But the vast majority of these units failed overnight.

In my reading of the 'F133 datasheet, this part has no brownout protection, nor a SVS module.  The BSL is a lower version than the 2.x that has the ability to disable the "Mass-Erase-on-Bad-Password" functionality.

My question is, has anyone experienced a similar situation with unwanted Mass Erase operations in these chips?  And what would be the best course of implementing a solid and decisive solution to prevent this?

  • 0
    TI__Mastermind 32405 points

    Hi Rod,

    Will you use the reset pin? If not you can configure it as NMI mode to avoid the  device go into BSL mode unexpected.

  • 0 in reply to Gary Gao
    Prodigy 80 points

    We only use the RST/NMI pin as part of the regular JTAG interface for programming the chip and debugging our software (we use CCS/Blackhawk adapter).

    If preventing BSL mode is the answer, would blowing the fuse work as well?  This would prevent BSL access through the JTAG Port.  

    I'm sure the problem we are having is the Mass Erase security function of the BSL, so disabling the BSL Seems to be the answer. Is there any risk of the BSL accidentally being invoked by the serial UART access method?  (We do not use that UART port in our application.)

    I will look into configuring the RST/NMI pin as NMI... thanks!

  • 0 in reply to Gary Gao
    Prodigy 80 points

    Hello agian~
    I revised the firmware to change the function of the RST/NMI pin to NMI, then disabled the NMI interrupt.  I verified that this indeed disables the Reset function in hardware.  However, this did not prevent the chip from being erased.

    A little more information on our problem, is that we have a situation where the system can end up in a situation where the Vcc supply to the chip is horribly unstable (See attached PNG photos).  With the board and the 'F133 chip sitting in this situation, it takes anywhere from 2 to 8 hours for the MSP430FF133's FLASH to get erased (even with the Reset pin disabled).  Of course, I'm working on eliminating the system's ability to do this to the poor chip's Vcc, but we also need to get to the bottom of how this could erase the FLASH.

    Presently, we have a 22K-ohm pullup resistor on the RST/NMI pin, and a 22K-ohm/330pf RC filter on the TCK pin, in all systems that have experienced this inadvertent Mass Erase problem.

    Above are two scope screenshots of the Vcc on the system in the errant state.

    Also, a question:  If disabling the RST pin (making it NMI) prevents entry into the BSL (as I see on Page 6 of SLAU319AE), how does my FET get control of the chip for Debugging?

    Thanks!

  • 0 in reply to Rod Martinez
    TI__Mastermind 32405 points

    Hi Rod,

    Thanks to share the information. I think the wrong password lead the erase by BSL is very small possibility because it should pass the CRC with the wrong password and correct packaged that is too hard to generate by a noise.

    The such unstable VCC maybe the reason. Due to it is out of specific condition and may cause unexpected operation like you see flash erase. Due to this device do not has SVS that will increase the risks. Have you try to add a huge capacitor at VCC to make it stable?

  • 0 in reply to Rod Martinez
    Guru 88460 points

    TI (wisely) doesn't specify what happens when you operate the chip out-of-specification, but a personal observation:

    Some years ago we tried powering an F2-series device with an experimental power supply. We discovered that the supply was capable of some pretty awful behavior, including negative and overvoltage spikes (much worse than the trace above). I didn't see a Mass Erase, but I routinely saw random Flash bits being changed. (Remarkably enough, the victim chip(s) sustained no permanent damage.)

    So I'd say there's at least anecdotal evidence that such a result is possible.

**Attention** This is a public forum