Tiva4C123 Processor failure

Feel your pain - but very little usable data complicates remote diagnosis.  Will present the most usual/normal "suspects" - you must provide the necessary detail.

MCUs are vulnerable to voltage spikes & inductive "kickback" - which too frequently accompany unguarded motor operation.  Useful would be the motor supply voltage, the connection path between MCU motor control outputs & the motor, and any/all sensing or control circuits which may introduce "illegal" voltage levels to the MCU. 

This vendor provides RDKs for BDC, BLDC, and ACIM motors - each/every one provides substantial design guides which you can model.  Our group has used MCUs provided here to run a variety of motors - some have been in near continuous use beyond 5 years.   Your (around 50) power cycle failure report likely indicates inadequate "buffering" of destructive transient or longer persisting voltage levels - which may have negatively impacted your MCU. 

As you've discovered - replacement of the MCU - minus a proper analysis of the real "failure mechanism" - is unlikely to yield a lasting cure.  Details - as outlined - are required...

Thanks. The issue originally came from our 240V AC power supplied board. Then we connected the board through a step down transfomer with 40V AC. Motor was disconnected and PWM was disabled. After 30+ power cycling, the processor was dead again.

This new data does not detail the requested connection path between your motor & the MCU.  That is needed.

In addition - your method of safely/properly powering the MCU - and insuring that the MCU is safeguarded from illegal voltage levels - must be detailed.

Sometimes such testing can be greatly eased/speeded by replacing the "offending" motor (or power device) with one of far lowered ratings.  Objective is to learn if the input power/distribution/command input signaling OR the output stage is the "primary" offender. 

Update: 16:44 CST - just noted your stmnt: "Motor was disconnected & PWM disabled."  Should that have been the case - then it is most likely that your power supply is not properly providing 3V3 to the MCU, and/or that some external command input or measurement signal exceeds MCU (+ or -) voltage specification, and/or that your board design or implementation prove faulty.  By removing any/all connections between the motor and MCU - you may be able to discover the source of your MCU problem...

We have a similair dead processor issue.  It was discovered there wasn't a direct connect between  pins 38 and 86 as referenced on the data sheet.  Instead each had it's own cap to power.  Failures occured within 10 power cycles. An external jumper was added between the pins and the unit hasn't failed.  Could not having a direct connect between the pins damage the chip when there are 2.2 uf caps on each pin?

Paul:

That's good information. Are you from Arrow? The problem is from Quantum. I'll forward your message to them.

Thanks.

Jay

Looks like we have a crossfire issue here on the forum.  I'm the one who's problem Paul was reporting on and I'm at Quantum.  Since Jay reported that he was conveying a problem at Quantum he must have been approached with the same concern by someone else.

As Paul posted we thought we had the problem licked by adding a missing external connection between the two VDDC pins on the part but that change was combined with replacing the pre-production (XM4...) part with a production part (TM4...) and in any case we experienced another failure on the board with both of those changes.

The first thing we did was to disable our 3.3v supply and check for voltage on each pin of the processor.  Doing that we found that +5 was feeding into pin 71 through a USB power control IC and we also found +5 on pins 26 and 27 coming from a CAN driver chip.  Both of those parts (the USB power controller and the CAN driver) have temporarily been removed from the board to eliminate them as a possible source of the dead CPUs but this has had no effect on the problem.  We also experienced at least one failure with this configuration on a board that did not have a motor attached. 

The last attempted "fix" was the replacement of the X part with a T part along with the wire tying pins 38 and 86 together.  That board lasted much longer (approximately 1000 power cycles vs 10-20 in prior tests).

We've gone through the schematic fairly carefully looking for any way that excessive voltage or current could be applied to a CPU pin and other than the ones mentioned above there don't appear to be any.  It's possible that there's some crosstalk between transients on traces in the high voltage section  but as near as I can tell all that is well isolated by physical separation and optical coupling.  Without a motor attached I think the only transient source in the HV section would be the mains charging the HV capacitor bank through a bridge rectifier.  There is a NTC inrush limiter in that path though and again the traces are pretty well separated from the logic and CPU.

HV section always deserves close scrutiny - we find.

Temporarily - might you replace this HV section with a lower voltage DC supply - that supply w/in the specifications of your 3V3 regulator?  And then power cycle this (ideally multiple boards) and observe.

We too employ a CAN xcvr - and it outputs 5V to MCU's RX.  (cannot explain your report of a 2nd "CAN delivered" 5V signal, though)  Thus far - over 1 year field/bench testing - have had no issues.

As stated earlier - beware of any/all external control/command signals/levels which may persist upon MCU power down and/or which may exceed maximum voltage rating of the MCU.

One more point (never say last) - suggest you build a board w/out the MCU - other 3V3 powered parts - and then data-log the 3V3's Reg.output upon power on/off.  We have observed multiple instances of such regulators, "transiently exceeding" their 3V3 output spec - upon power-up - especially when powered from at/beyond their input Max_V rating.  Insure that regulator maker's spec for input & output C also is met/maintained.

Using over 8 different versions (all Stellaris) we've had zero such MCU failure issues - dating to 2007... (no experience w/rebrand...)

Update: 15:02 CST - We can assume that vendor's closest, "launchpad board" to your need is designed/built correctly.  Acquiring several - then powering from your HV section (after identical V Reg treatment {as per your board})- may be a good means to, "pass/fail" chip-killer capability of that HV section...

Are you using the EEPROM on the micro ? If yes, you may be hit by this Errata - "Device may Become Non-functional if an EEPROM Write or Erase is Interrupted"

Yes, we use the flash based EEPROM. Does "Device may become non-functional.." means the chip is totally dead, and even cannot be recognized by the emulator?

Update: By the way, the EEPROM is executed in the background. A state machine is used for EEPROM operation. So in theory, the EEPROM read/write shouldn't be interrupted.

Thanks.

You can refer to the Errata document for further information on the Errata - http://www.ti.com/lit/er/spmz849a/spmz849a.pdf

Your initial post appears to be referring to power-cycling. If you can confirm that you are not removing power during EEPROM writes/erases, you should be safe; at least based on my understand of the errata.

Thanks. We'll try to remove the EEPROM operation and test to see what happens.

Jay Bu1 said:

Paul:

That's good information. Are you from Arrow? The problem is from Quantum. I'll forward your message to them.

Thanks.

Jay

Jay, are you working with someone at Quantum?