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

MSP430F5436 Blown Reset while on FET

Mark Wyman
Prodigy 130 points
Other Parts Discussed in Thread: MAX232

Hi all,

We are using the titled device for a complex embedded low-power hand-held device, and have run into a recent issue where the reset I/O gets stuck hard low if left connected to the MSP-FET430UIF. The reset pin winds up measuring 0.6 ohms to ground after the blow, power or no power applied. It seems the reset I/O is permanently damaged once this occurs.

This interface has been working fine for a couple of years, and this particular version of PC board for more than a year. I however upgraded Code Composer v5 to the latest emulator and other modules on Friday 10/2/12. Right after this change is when problems began to occur intermittently with this reset pin. I have now managed to damage 3 boards this way, and have no idea how this is occurring, but suspicious that some signaling event driving the reset pin through the FET is causing damage. Is it tying the reset to some internal higher voltage? Who knows. I cannot trace the problem as it is a long term issue where the board will be fine for 2+ days, then suddenly will die with a shorted reset pin. Of course at this point the device will not run with or without the emulator in-place.

Some more information: This board was running from a battery with USB power, and debugger pod is attached to the same PC with the same ground. No ground loops that I am aware of (or can identify). Signals on debug header do have some ringing, but overshoot no more than 0.3V. A LiON battery charger was running during this time, but is on a different board in a stack of two boards and well isolated from the MSP430. It has blown the reset without a battery attached also.

Monitoring TDI and TDO reveals JTAG communication continues in and out of the part while attempting connection, all other JTAG signals look fine during the probing process. RESET however is stuck low the entire time so of course the connection fails.

Diagnosis: The 22nF reset line capacitor is fine in all cases, we have a 10K pull-up and is fine in all cases. Otherwise connection is simple: FET->JTAG Connector->Pullup, Cap, Reset pin of MSP430.  Device is running from between 2.65V and 2.75V depending on standby vs full on mode. When programming I have let the FET pod power the device up to 3.0V without any difference in behavior. I was hoping my supply voltage was just a bit marginal, but does not appear to be the case.

Death seems to occur simply while code is executing but always while connected to the FET. I have seen where my processor will randomly reset and the reset event is called a standard reset according to logs (not like a watchdog). It was rare so I discounted it, but now I am not so sure. This random reset event does not damage the part, but it is curious in that it occurs at all. Without the emulator connected, these random resets do not occur.

TI Emulator is at version 5.2.4.17, MSP430 Emulators at 5.2.1.4.

FET firmware version 3.02.04.005 according to ElProtronic software.

Anyone run into anything similar or can guide me in my investigation? This problem is a stinker due to the long-term intermittent event.

Also, any examples of protecting the JTAG interface for production programming on the MSP430-side? (Meaning rarely accessed) I would normally use some protection diodes, but the threshold of the diodes in the MSP430 is so darned low, it is hard to identify a passive part that would do any good.

Thanks for any help.

-Mark Wyman

  • 0
    Guru 227245 points

    I wonder why this happened now and didn't happen before. It shoudl be eithe rimemdiately or never. But maybe I have an explanation.

    First, all MSP pins, including RST, have CLAMP diodes to VCC and GND, protecting against over/undervoltage. However, these diodes can only sink/source up to 2mA rated current. If thsi current is exceeded, the diodes will melt and either open (leaving the port unprotected) or (more often) short to GND or VCC.

    If you apply a negative voltage to RST (< -0.2V, >2mA) this may cause the clamp diode to melt and the pin may remain shorted to GND.

    How can this happen? I don't know. Maybe a problem with the common GND between board and FET. If the board is self-powered but connected to the FET power pin on the connector (instead of the sense pin), this may cause the FET GND to go below target GND (if the GNDs are not properly connected9 and then the FET signals will be below 0V.
    Unlikely but not impossible.

  • 0 in reply to Jens-Michael Gross
    Prodigy 130 points

    One interesting tidbit I have thought up while eating lunch is that the charger USB is being powered through a USB hub, where the emulator is directly off of the PC motherboard (case). I suppose it is possible that the charger turning on and off is causing the power supply on the hub to go bonkers. We all know how well some power supplies are on very cheap products like USB hubs.

    It has always been connected this way, but the charger code has been refined and cleaned up. Perhaps the cycling on and off of the charger when the battery is full/not ful is causing some spurious problems.

    For now I will try and run the emulator and charger both from the main PC rather than through the hub and see if things change.

  • 0 in reply to Jens-Michael Gross
    TI__Expert 3170 points

    Can you remove an ESD devices and confirm the damage on those devices and not the MSP430 reset pin?

  • 0 in reply to George Peterson
    Prodigy 130 points

    There are no ESD devices on our board. It is tough to find ones that will conduct before the threshold of the JTAG pins and not effect the SI of interface. Since the pins were only to be used in a static-free manufacturing process, it was not considered. The best bet as far as I can tell is put in some "sacrificial logic" with a better tolerance to surge events, but that seems a waste for program once, pop IP fuse and call it a day.

    To get 2mA or more something through the MSP's reset pin protection diodes with nothing in-between the debugger and my board is almost impossible without some sort of major fault condition on the FET, perhaps my FET is failing. Only thing I was thinking is the reset pin of the MSP was set to an output/open drain while the debugger FET pod was also set to an output set high and then forced a meltdown on the reset pin. That is why I am suspecting the FET has a bad state in it with the latest image, though I cannot imagine this being true or it would happen much more often.

    Anyhow I am still looking into it.

  • 0 in reply to Mark Wyman
    Guru 227245 points

    Mark Wyman said:
    To get 2mA or more something through the MSP's reset pin protection diodes with nothing in-between the debugger and my board is almost impossible without some sort of major fault condition on the FET, perhaps my FET is failing.

    Or detecting a wrong VCC from the board, or having the GND conenction failing, so the current flows through other channels.

    In additon to the internal clamp diodes, you may add external clamp diodes to VCC and GND (like BAT42). These might be slower but will kick-in soon enough befor eth eitnernal ones overload. Adn can stand much more current.

  • 0 in reply to Jens-Michael Gross
    Prodigy 130 points

    What is interesting is I had pin death with the Debugger interface working just fine over a weekend with common grounds, so unless there was an electrical storm, it is unlikely that a ground failed or something in the system changed to a degree of blowing the reset pin unless it was borderline dead already from a prior event.

    I am going to put a resistor in-series with reset and watch the current through it differentially over a period of time to see what transpires. Of course inserting a resistor will likely make it work just fine.

  • 0 in reply to Mark Wyman
    Guru 227245 points

    Mark Wyman said:
    Of course inserting a resistor will likely make it work just fine.

    Well possible. IIRC, newer versions of the FETUIF do already have a series resistor of 1k.
    Such a 1k series resistor will make the inputs of a 3.3V powered MSP 5V tolerant (at the expense of 1.5mA wasted current). I used this often in the past (with 5V MAX232 RS232 converter or other TTL peripherals)

  • 0 in reply to Jens-Michael Gross
    Prodigy 130 points

    Hmm,

    I think it would be best if I just ordered a new FET and called it a day. This FET is NOT a newer variety if V1.3A means anything. Still have not had a chance to put a series R in there, other things going on.

  • 0 in reply to Mark Wyman
    Guru 227245 points

    Mark Wyman said:
    This FET is NOT a newer variety if V1.3A means anything.

    I think the series resistors were one of the differences between 1.3 and 1.4. But I don't have the schematics at hand for verification.

  • 0 in reply to Jens-Michael Gross
    Prodigy 130 points

    Opened it up, it does contain resistors.The guts look good with no char marks on anything obvious. I didn't poke around to see if anything was going crazy.

    Another one bit the dust overnight by itself (gave up the ghost, kicked the bucket, etc)

    Something somewhere is damaging the reset lines on my parts. A board/MSP430 died overnight between disconnecting power leaving it, and re-connecting power in the morning. Same failure mode with a shorted to ground reset pin which cannot be recovered. Nothing was connected to the JTAG or reset pin when the device was running. ESD workstations and straps have been in-use, we are careful with that.

    The theory is the reset was already partially damaged during a programming event, and a power-cycle finished it off. Otherwise we have no idea what could be causing this apart from some major power glitches or bad programming sequence. To prevent ground loops, I have all grounds tied together at my workstation now just to be sure.

    Please note again that this hardware has been in-use for some time, and until a recent Code Composer update which also updated the FET firmware, we had no problems.

    I will be speaking with TI support today, and hopefully will come up with a solution. I will post back here to our findings.

  • 0 in reply to Mark Wyman
    Prodigy 130 points

    So far it seems that when we updated Code Composer on my machine, it lost the target voltage setting and it restored the voltage to 3.0V as a default. Unfortunately I was using the FET to power the debug interface while simultaneously powering the MSP430 with 2.65-2.7V. So when I lost my setting, it was over-volting the JTAG interface. Oddly though, I observed a 3.3V 6mS long pulse on the reset pin while it was probing for a device.

    I have made the changes to power the FET IO from the target instead of the FET voltage setting to avoid this problem. There was a time when we needed to power the MSP430 from the FET, but this is no longer the case. If the voltage setting and the power of my board were both 2.7V, there was no problem, so when the update lost my setting, I started having problems. I will report back in a few days to declare this issue closed or not.

    Note: I could swear I checked this setting after I ran into problems, but perhaps not.

  • 0 in reply to Mark Wyman
    Prodigy 130 points

    It seems the problem is resolved. No more blown reset pins in a while.

    The interesting part of this was it would damage the parts, but the damage was not noticeable for some time after it occurred making diagnosis rather difficult. For example I could program a device several times with no apparent problems, but then the board would be moved somewhere else, run for a few days, then suddenly die with a shorted reset with no apparent trigger. Especially since the reset line at that point was not connected to any external debugger.

**Attention** This is a public forum