Did I accidentally burn my IC via USB0VBUS line?

Did you try a complete erase with the LM Flash Programmer?

It hapened something similar to me before

Hello David

If the 1.2V is coming up, then your device may still be working as the internal regulator is still operational. BTW, how do you know that the device is not working?

Regards

Amit

When I plug the toasted board to the USB port, it still shows up in the device manager as software upgarder, but LM flasher will never recognize it --- so yes, it still has some functional blocks, but I doubt it is fully functional

The reason I said it was toasted is because it indeed has a burnt crack on top of the plastic and it still gets hot in a small region near that.

Hello David,

If Windows PC Device manager shows it up as a DFU but LMFlashProgrammer still dos not recognize it would not necessarily mean that the device is toasted. If possible try to use JTAG debug to see if you can get entry to the device.

Also as you mentioned that it has burnt crack which gets hot, would make me to think that it may have some issues. The USB Pads are 5V tolerant pads and have ESD fail safe on it. So it may not be the cause of the problem, as on the launchpad also we use the same path for the ICDI. I can;t think of anything right now other than applying power to the "new" MCU and then connecting the USB cable.

Regards

Amit

Noticed the IC is TM4C1294NCPDT13 on my board, but XM4C1294NCPDT12 on the launchpad

Any difference?

Hello David,

Then you have the production version with you while on the LaunchPad it was the pre-production version.

Regards

Amit

Any chance you may help me to get a few more TM4C1294NCPDT? I can't find it on digikey nor our local distributor. If I can have a few more, I don't mind to use the spare to give a second try, since we don't see any reason it should burn out this way.

Hello David,

mouser may have some but on order. I am not sure how much would be the lead time on that.

Regards

Amit

How about the availability of pre-production version? since TI is shipping the launchpad, you should have that in stock

Hello David,

The LaunchPad would also switch with production version. If you can get parts on the TI website with the same version, it could do the job.

Regards

Amit

Hi Luis, Could you give more detail on what happened?

FYI: My 1294 was fresh from TI so I assume it was empty.

Hello David,

Luis, would be referring to erasing the flash content using LMFlashProgrammer. The parts do come empty.

Regards

Amit

David Chance said:

USB0VBUS is the ONLY pin on TM4C1294 that is 5V tolerant, so when the 5V reaches the GPIO, it toasted the GPIO function block

@Amit,

Glad poster solved - yet his explanation (only one pin on xxx1294 is 5V tolerant) seems a huge step backward.  (i.e. our far older LX4F {condemned} devices enjoyed multi-pin, 5V tolerance)  Might you advise - dispute or confirm such "single pin, 5V tolerance by xxx1294?"  (I'd bet against poster's finding/assertion)

Also - the application of 5V to a single gpio - in our experience - is unlikely to kill the "entire gpio function block."  (Pin sometimes/maybe - that entire port - doubtful {especially if the "offender" truly was limited to +5V})

I confirm the offender is indeed 5V.

The damage can't be truly verified, since I have replaced the IC, but the burnt crack is not immediately next to the pin, but a few mm from the edge of the IC, but I think it is irrelevant if just the driver of the pin or the function block of the pin, or the exactly what associated with  the GPIO pin is damaged.

David Chance said:

Note: All GPIO signals are 3.3-V tolerant, except for PB1 (USB0VBUS) which is 5-V tolerant.

You've done a good job in fixing & responding - I applaud that.  Yet - having been trained in law & engineering - suggest that you look bit more closely @ data enquoted.  Especially of note is the wordage, "All GPIO signals are 3V3 tolerant!"  That's suspicious - is it not?  Never has our small tech group seen such gpio described as 3V3 tolerant - when the MCU is 3V3 powered.  That's of course, expected!   1V8 powered MCUs may better (& properly) announce their 3V3 gpio tolerance.

Suspect instead that sentence should have (properly) read, "All GPIO signals are 5V tolerant!"  It almost seems as if the voltage (sense) of those 2 sentences was inadvertenly "flipped."  (thus my request for Amit to serve as vendor's interpreter...)

Well, while waiting for Amit to clarify that, if you have a spare TM4C1294 launchpad to kill, you can try to apply 5V to PE2 (pin 13) and see if you smell something  :)

Our small group is not fond of xxx129 series - have none.  (we use multiple ARM MCUs - multiple vendors (M0, M3, M4 (123 series here) & new M7) - yet clients may use and that's the basis for my question {targeted to Amit for absolute clarification})

You're silent as regards the "strangeness" of, "All gpios are 3V3 tolerant!"  That writing sets off alarm bells in our office!

Hello David,

TM4C129 does not have 5V tolerant IO's other than the USB Pins. TM4C123 on the other hand had all IO's 5V tolerant.

Regards

Amit

I believe the core of 1294 is powered by 1.2V so TI would like to clarify "ALL GPIO signals are 3.3V tolerant"

Well, let Amit be the judge

Thanks, sounds like cb1 lost his bet :D

Hello David,

Both TM4C123 and TM4C129 have 1.2V core. The IO's are 3.3V operation for both. Except that TM4C123 has all IO's as 5V tolerant which is what limits TM4C129

Regards

Amit

I think it's correct be explicit that the pins can suport up to 3.3V. It also notes that even if the MCU VCC is something like 2V, they still can have 3.3V inputs without being damaged

Indeed cb1 (& other ARM MCU users - "used" to normal/customary GPIO tolerance to occasional 5V signals/levels) lose.

As this is such a change from past Stellaris, and LX4F and TM4C - (and most all other ARM MCU vendors' MCUs) the manual may "duly and better note" (i.e. highlight) the fact that xxx129 family "breaks" from the long past comfort of, allowing 5V upon "normal GPIOs!"

Far better language - imho would read not 3V3 tolerance but instead: CAUTION - unlike most all other ARM MCUs - the GPIOs w/in this device - are LIMITED to 3V3 (maximum) input signal levels.  This may well save those who may predictably, "suffer" rather than, "benefit" from their past ARM MCU experience... (i.e. 5V GPIO are normal/customary) 

None in our group can ever recall reading of a 3V3 MCU's GPIOs described as, "3V3 tolerant!"  (might this be a, "most indirect/hidden" way of stating that this MCU's GPIOs are uniquely, confined/limited?)  Rings (sadly) of the past (then little known) NRND wordage/camouflage - assigned to departing M3 Stellaris - does it not?...

Beyond this unwanted/unexpected, "restriction" upon "normal" GPIO signal levels it should be further noted that the I2C API has also been forced to change to accommodate this new MCU.  Breaking from the past, "known/practiced" rarely occurs w/out "upset" - such altered highways should be (effectively) marked!  Indirect/unusual language does the user base no favors when breaking from long-standing (5V I/O) tradition.

Caveat Emptor - alive/well - under 129 family, here...

Hi Amit,

Although the datasheet says all GPIOs are 3.3V tolerant, but on page 1820, Table 27-7 and 27-8, there is this statement regarding the 4V Max input voltage for GPIO pads

Can I assume all GPIO pads can handle 4V instead of 3.3V? Or it is another typo?

Hello David

The maximum rating will not damage the device but will affect the reliability over extended periods of time. That is the first note before the table begins.

Regards

Amit

David Chance said:

Can I assume all GPIO pads can handle 4V instead of 3.3V?

Two things you may wish to consider - imh (yet experienced) opinion:

a) as Amit states - operating any IC @/near its "max" is sub-optimal - should be avoided

b) hard to imagine how - & from where - you'd harvest signals at/around 3V3 - 4V0.  Can see an occasional analog signal - but those digital should peak on/around 3V3 or 5V0 - depending upon source.  We're curious how/where you'd source "multiple" signals between 3V3 & 4V0...  (and may be able to suggest efficient work-around - should those levels prove, "real.")

At the beginning of the discussion, I was considering to have a CPU board that may handle both digital input and analog inputs, that was why I may go over 3.3V inputs on GPIOs since they also serve as Analog inputs.

The last post was simply a friendly poke at TI just in case they had a typo like the one I shown them before