TM4C1233H6PM: Tiva MCU burned

Feel your pain.       You write, "Sometimes, devices come back non-responsive."     That's not too quantitative - is it?

Far more useful would be the, 'Percent of Total Devices' which exhibit this failure ... and - is this a 'new' occurrence?     (i.e. have these devices (past) succeeded - and 'only recently' - this failing has been noted?   Should this (recent failure only) have been observed - what might have changed - your past board builds (success) vs. these newer  ones?    (failing)

The fact that the MCU's external xtal drive has been lost - most often - points to a 'reasonably severe' power disturbance - inflicted upon the MCU.   As the vendor agent noted - I doubt the CAN bus to be causative.    More likely - the powering (both turn ON & turn OFF) of your 3V3 Regulator - rises in my suspicion.     The 5V Supercap concerns - it would pay to scope monitor [really capture & store] (both) the 5V and 3V3 waveforms  - during  Power ON and OFF!     From experience - sometimes that Supercap (tied to the output of your 5V Reg.) will 'hold-up' that  5V Reg's output voltage  (creating V_Reg_Out > V_Reg_In)  when the voltage input to this 5V Reg. is decaying/removed.     That's an 'illegal operating condition' - and may cause the (following) 3V3 Reg. to misbehave - spiking your MCU.     (that so - at least in theory...)

If not already present - small value, fast acting, ceramic (bypass) caps should be present upon (both) the 5V & 3V3 power lines.      You'd want such caps ALSO (very) close to the MCU's (multiple) Vdd pins and to VddA.      (even if - especially if - you are not using the analog features of the MCU!     You must connect VddA to 3V3 - even if analog is unused)      (I would go so far as to REMOVE the Supercap - at least during early testing - and closely monitor operation - to learn how (or if) this impacts.)

You need to, "Induce this failure more deliberately  AND at higher frequency" - so that you can best detect the impact of your various correction strategies.     I believe that 'Power ON & Power OFF CYCLING' should be introduced - possibly w/the MCU programmed to toggle several LEDs (which may be remotely monitored) and which 'immediately' detect and ANNOUNCE  your MCU's  Failure!      Suggest 'Power Up and ON' for ~ 10 seconds - then 'Power Down and OFF' for ~5 seconds.     (enabling 4 complete Power Cycles per minute - nearly 1K Cycles w/in 4 hours...)

Divide & Conquer always helps.     If you provide a termination resistor on the 'outboard side' of the CAN Xcvr. - but break the CAN interconnect - and then repetitively execute Power ON/OFF - that may eliminate the CAN connection from 'guilt' - should your MCU continue to fail.

Your MCU's JTAG lines should not float.      (or be terminated by the 'too high' value, MCU internal pull-ups - 10K or less (external Rs) [even grafted in] which prove far superior in adding signal robustness & reducing the  'invitation'  of  damaging,  'transient signal invasion.')

HI Christian,

Christian Steiniche said:

We remain very interested in suggestions to above.

Adding to CB1's excellent excerpts, if not already covered might you consider info below.

Seemingly your 5v buck down regulator to 3v3 for powering MCU VDD pins can perhaps overshoot during power up. Please check the datasheet to determine how much overshoot might occur as the buck down switcher powers up. We opted to use 3v3 LDO regulator in such a buck down scenario which provides an output voltage safety clamp if 3v3 overshoot might occur. Buck down regulators often may not buck 5v down to 3v3 on the first few switch pulses.