TM4C1233H6PZ sudden death

Hi, 

Could be a hardware problem, if the main oscillator is not working anymore - look for bad solders or bad input/output configurations/states or even worse, a software problems. These ones occur when less expected, could be due to various cases. Start by analyzing what triggered such bad behaviour - a new command, a new event - could be stack problem if a new function was requested when it crashed or just a piece of software with hidden problems.

Petrei

Believe that few more facts will aid diagnosis.

a) How many custom boards in total were built, test/verified?

b) How long were the initial boards run during "test/verify?"

c) Does you internal test/verify include time w/in "shake/bake" chamber - to weed out inadequate solder joints/connections?

Intent of the above is to determine if your testing procedure meets, "normal/customary" test/verify protocol and to learn the size/scope of your issue.

d) How observant of ESD is your shipping/handling - as well as that of receiver/user?

e) Usually your board must some way/how "connect" to outside world.  Were all such "outside world" signals constrained to MCU specifications?  At all times?  Might those off-board signals have been introduced while your MCU board was unpowered?

f) Monitoring at OSCOUT may in itself cause issues.  When/where possible - our tech group tries to reserve a Timer pin which may be teased into a 1:10 (frequency) output of MCU's system clock.  As this is a low impedance output - it's far less likely to disturb that which you seek to measure.  (i.e. how do you "measure an electron" w/out disturbing the electron - thus eroding your measurement?)

We've beyond 10K of this vendor's Cortex M3 and M4 successfully deployed (some in relatively hostile environments) we've rarely (perhaps never) noted your incident...

Hello cb1_mobile,

thank you for your food of thoughts. The main object of my inquiry was to get some hints, whether the processor is still alive or not. Meanwhile we did some in-depth investigation on our issue and found, that VDD voltage is switched on / off within 500 ms for several times due to external system behae not adequate operating conditions for a integrated circuit, but among the processor we have a FPGA and some full custom ASICs which tolerate this behavior. Also in the past we brought out several very complex designs running in 50K volumes, which also tolerated the described power cycles without any damage.

Is there any known sensitivity of TM4C1233H6PZ to several power cycles within a short time interval?

I am familiar with latest errata sheet of the TM4C1233H6PZ, but no item pertains to our application. It seems to be a new errata.

By the way our processors are mark within DID1 Bit/Field 1:0 = 00 corresponding to Engineering Samples. Is this the usual Qualification Status?

Best regards

Thomas 

We've used various MCU's since early '80's - such sensitivity to power disturbances seems rather typical (imho) and is not any weakness unique to this vendor.  We strive to have our MCU's power very properly behaved - meeting vendor's prescribed "rise-time" - and as free as possible from dips/drop-outs etc. (i.e. larger Caps prior to 3V3 regulator often assist)

While (somewhat) active here - such "Vendor insider information" questions/issues are best handled by the very able, vendor's Amit.  Wish you well.

cb1 to Amit, "Allez!" (s'il vous plait)

Hello Thomas,

Are you using EEPROM on the device?

The issue that you mentioned looks to be synonymous with a known errata on EEPROM with Power Failure.

As for the qualification status, all TM4C devices are qualified when ordered via distributors. The issue in the DID1 is a known one and will be a part of the next errata release.

Regards

Amit

Hey Amit,

it took some time to double check, if the EEPROM is used for writes on our device. So I flashed code to the device, whose EEPROM access is eliminated definitely. We started our test procedure, but the device became non-functional again. I also can report some progress. Before one of two test cycles led to a non-functional device, now we had one of ten test cylce which produced this failure. However these tests are not representative in lack of sufficient TM4C1233H6PZ devices and the time-consuming replacement of the damaged devices. So I suppose another issue on the device.

Is it possible to get samples of the latest revision of TM4C1233H6PZ?

With complements

Thomas 

Hi,

As many microcontrollers in use today are provided with brown-out detection circuits, this could be also your case, since the interruption time of 500 ms is big enough to cause reset/brown-out intervention. If not properly configured, this can lead to on-chip bootloader activation, giving the behaviour of non-functional device. 

If the initialization phase is not OK, will be signaled by toggling TDO pin.

Check the EN bit in BOOTCONFIG register - see also the user manual for this.

Petrei

Hello Thomas,

When the device stops responding, did you try to put the "dead" parts on some sort of socket boards to verify if the device resumed functionality? Also did you attempt a Unlock Sequence using LMFlashProgrammer or UNIFLASH (would require a Stellaris ICDI, can be got from the LaunchPads)?

I would suggest sending the parts back to TI for FA to see what could be the issue.

Regards

Amit

Hello Petrei,

Brown out event action is programmed to cause a reset of the microcontroller for BOR0 and BOR1. If the power cycle accidently enters bootloader I would have the chance to reflash the microcontroller with UNIFLASH or LMProgrammer, but I get no connection to the microcontroller (USB upgrade).

TDO pin isn't toggling, so initialization phase has ended without errors or never has startet!

Regards

Thomas 

Hello Amit,

yes we tried to reactivate the device with UNIFLASH and a XDS200 debugger using the Unlock Sequence, but we had no success.

Sending back the devices to TI for FA is a good idea. Since we have no on-site contact person, could you point out the procedure please. i suppose an failure / issue description will be necessary.

Best regards

Thomas

Hello Thomas,

I am not sure if XDS200 will support the JTAG-SWD switching required for the unlock sequence. As for the return of devices please use the following information. In most likelihood you have to send it back to the distributor.

"For information on how to process returns, please contact your customer service representative, TI authorized distributor or TI's Product Information Center. Once returns are received at TI, they undergo appropriate testing and analysis to confirm customer concerns."

Regards

Amit

Amit Ashara said:

please contact...TI's Product Information Center

No easy job that!  (reaching local KGB/CIA operative may prove easier)  Long live (ever helpful) corp-speak...