TM4C1294NCPDT: TM4C1294NCPDT

Darin Grasso said:

The failure manifests itself as loss of communication during operation. 

Hi Darian,

  Can you elaborate what type of communication is lost? 

Darin Grasso said:

The application note is followed to the letter. 

Which application note are you referring to?

Darin Grasso said:

I've probed the circuit for power transients, etc., anything that could possibly damage

the part but found nothing.

Are you saying the part is current damaged? Nothing is wiggling on the pins? What is the difference compared to a good working part?

Darin Grasso said:

Can we please return damaged parts for failure analysis?

I think we should diagnose the problem further before concluding the issue is due to the MCU reliability. We need to know if the MCU is subject to electrical overstress or the part operating out of spec for any duration. 

Hello Charles,

Thank you for your reply.

The communication failure is USB com, ethernet, all I/O lines go quiet. It appears the device stops executing. 

All voltages and reference appear normal when the part is working or has failed. 

A good working part has all I/O pins functioning.

The application followed DS-TM4C1294NCPDT-15863.2743 SPMS433B data sheet.

Hi Darin,

  If you use a debugger to connect to the device, where would the processor stop/stuck at? 

  If you can successfully connect to the device with a debugger, can you reload the same program? After reloading the same program, do you see any difference. The assumption is that you can still connect with a debugger. I will even suggest you load a simple hello example. Will you see UART communicating? Do you see the GPIO toggling? You can even try the TivaWare Ethernet example or USB example. 

Hello Charles,

Thank you for your reply.

I'm consulting with our firmware group to answer the above question.

I will get back to you thanks.

Hello Charles,

When connected to a debugger there is still no communication.

No chance to reload a program. 

No contact with the UART and no GPIO activity.  

We have several failed units that exhibit the same failures. 

Thanks

Hi,

  I feel it is likely some kind of electrical overstress that might have damaged the devices. For the failure devices, please show their device marking. What I can do is to have our team do some internal investigation if there is any production abnormality from the wafer/lot these failure devices come from.  Can you do a ABA swap test? This is to fully isolate the problem is not due to the board. 

The A-B-A Swap Method is a simple cross check test, which can confirm the observed issue is not systemic.

• A-B-A Swap Method
  (1) Remove the suspected component (A) from the original failing board.
  (2) Replace the suspected component (A) with a known good component (B) and check if the original board now works properly.
  (3) Mount the suspected component (A) to a known good board and see if the same faliure occurs on the good board.

Step 3 is important because it helps us to exclude any possibility that the issue is caused by a systemic issue or the interaction of multiple slightly bad components on a good board.

Hello Charles,

Thank you for your response.

We've performed the A-B-A experiment.

Consistently a failed device exhibits the same lack of communication regardless of PCB. 

The Tiva is isolated from any other unit failure. 

Attached are pictures of 6 failed devices showing part #, etc. 

Thank you.

Hi Darian,

  I will get back with you on my findings for these materials. They are all from the same fablot. 

Hi Darian,

  Our internal investigation does not show any production abnormality on the fablot from which these chips are from.  These are 2020 materials. Have these chips been on the field since 2020 until they failed? In another word, how long have these chips been on the field before they lost comms?

  Please tell me where you sourced these materials from. 

  Can you show me your board design schematic?

  Does the MCU communicate with other devices that are not on the same board? It is important that I/Os that go to another board are diode protected. 

  I understand that you say that the power supply is normal. on these failure devices. These devices are currently non functional anyway.  But it will be hard to tell if the MCU or any I/Os were subject to out of spec transient during operation. 

Hello Charles,

Thank you for your response.

Our source is Arrow electronics.

I do not have the authority to grant TI access to our schematic.

My boss has requested that he handle this issue going forward. 

I need to put you in direct contact with him at this point.

His preferred communication is Email.

Please provide Email contact.  

Thanks

Darin

Hi Darian,

  You or your colleague can communicate with me through the private message within the e2e by adding me as a friend.