TM4C1294NCPDT: Weird USB problem

Hi David,

That is very strange... can you get any IC images or at least the lot information from the IC which we can use to do a look up of the lot history?

Were the parts sourced from TI or a distributor?

Have you done any A-B-A swaps to see if the issue follows the IC to known good boards that are working with older TM4C devices?

Best Regards,

Ralph Jacobi

Here is one in front of me:TM4C1294NCPDT1314AHRTW, I think we got them from your distributor

I will see if i can do A-B-A swaps, but it is not an easy task

Hi David,

Thanks, usually not my first step on such issues but we've seen the occasional non-genuine part so wanted to be certain of that first... good news is that it checks out from what I can see.

The issue itself to me is really strange, I am going to check with the product team in a bit more detail here about the lot specifically, but the A-B-A swap would help a lot too.

Another key question here is you mentioned 'batch', how many devices/boards are showing an issue vs how many are working?

I'm trying to think still why that issue would occur on the USB lines but I really can't come up with an idea from an application / software standpoint... especially when the usb_dev_cserial example is an issue. When using that example, what were you trying to plug the USB into? Just a windows PC?

Best Regards,

Ralph Jacobi

I found several out of this small batch (we can't find enough IC from TI these days, do you have any insight on when TI will fix its supply problem?), but since I have never seen anything like this in the past ten years, I come to you. I was trying to plug the USB to Windows PC when using usb_dev_cserial example

It can still be hardware issue in our end, but the way it acts pointed at the processor since there are only a few lines involved in USB operation

Hi David,

I haven't gotten further feedback yet regarding my query.

Also 'several out of this small batch' is pretty vague still. Trying to understand if this is 3 out 10, 10 out of 500 etc.

Do you know if there have been any BOM adjustments/changes due to the semiconductor wide supply situation?

Regarding the question about supply, I don't have any information on that front to share, sorry.

Best Regards,

Ralph Jacobi

David Chance said:

When I run the program, USB port never generate interrupt (USBP line is low (it should be high)

Sounds to me the VBUS pin is partially shorted, +5v tolerant but still needs series R to limit injection current. Past we have had several MCU fallouts of launch pads XDC110 USB port VBUS pin has very low ohmic resistance to ground plane. Yet CCS debug would often connect. VBUS pin should measure roughly 8 megohms, if <300 ohms the MCU is toast!

due to part shortage, we only build a few dozen and tested a few, and found only two so far. Yes, there are some BOM adjustment, but USB port really has nothing extra, and both work in bootload mode, so it was very strange to me. 

VBUS pins still reads high impedance, over 8M Ohm, and since it works in bootloader mode, it is not toasted

BTW, there was no resistor in series to VBUS in launch pad design, see https://www.digikey.it/htmldatasheets/production/1751880/0/0/1/ek-tm4c1294xl.html 

And we had never had any issue with this configuration

David Chance said:

BTW, there was no resistor in series to VBUS in launch pad design, see

Yet the VBUS pin is easily damaged from reverse USB port current in some cases. Adding a 100Ω series resistor on VBUS stops it from being destroyed.

David Chance said:

since it works in bootloader mode, it is not toasted

That is not an indication the VBUS ready register control bit is being toggled for Device mode. Does your custom boot loader check USB register VBUS ready bit toggles high? Check the USB register VBUS control bit via CCS debug (continuous refresh) to check register bit has indeed toggled high. 

David Chance said:

And we had never had any issue with this configuration

Perhaps pure luck, you should go to Vegas play the slot machines 

1) If this resistor is so important, TI really should get it right with its launchpad schematic

2) In one of my tests, I was using TI's example usb_dev_cserial directly, without custom boot loader at all

I may have pass it, but I didn't find such warning in its manual either (https://www.ti.com/lit/ds/symlink/tm4c1294ncpdt.pdf) Could you be so kind to point it out?

Ralph Jacobi , Could you clarify this matter brought out by GI directly?

David Chance said:

Could you be so kind to point it out?

School of hard knocks is not a college course, comes from experience and many years dealing with the product.  The vendor is not taking a straw poll to ask how many shops had issues with VBUS pin.

David Chance said:

I was using TI's example usb_dev_cserial directly, without custom boot loader at al

Again have you checked the USB register VBUS ready bit via CCS debug is toggling?

The IC was replaced per Ralph's suggestion. 

We have used about 20K TM4C1294s, I can't imagine pure luck runs so long

David Chance said:

The IC was replaced per Ralph's suggestion. 

Well I guess you have your answer then, or do you .

The issues I mention are due to many times plugging USB type 2 port into computer. Or USB hub that was found to have no bypass caps on the +5V VBUS pin of connector. This issue has been reported in the TM4C forum by other posters over the past decade.

David Chance said:

We have used about 20K TM4C1294s, I can't imagine pure luck runs so long

You really need to be sure VBUS ready bit toggles high in the R3 silicon devices you suspect as being an issue. If the bit never toggles high inside CCS debug you have one or more to investigate as to why.

Hello Gl,

Genatco said:

This issue has been reported in the TM4C forum by other posters over the past decade.

This is simply not true. The only posts searching for this issue brings up are the ones you've raised. Please refrain from making sweeping statements based on your personal experiences.

Best Regards,

Ralph Jacobi

Ralph I personally reported several times this forum the VBUS pin fails to toggle USB ready bit for device mode entry. Several XL launch pads that slowly VBUS pin became shorted to the ground rail diode. Why the poster has yet to acknowledge ready bit being togged in CCS debug for his custom boot loader mystifies.

As I said before, there were NO custom boot loader involved in one of my tests. 

David Chance said:

When I run the program, USB port never generate interrupt (USBP line is low (it should be high)

Could explain what is the P line? What MCU pin number Table 21-1 are you referring to? Ralf is an expert on Tivaware USB device drivers and has helped many posters with dire control issues. He is to be credited with solving some of the most difficult USB device issues.

David Chance said:

I connect it to PC via USB and use JTAG header to debug it directly

Please elaborate how are you debug directly, with CCS or some other IDE? Are you referring to XDC110 JTAG device from TI or a Black Hawk JTAG device or other?

This register indicates USB ready when bit set (1) if VBUS pin is getting into the device layers. Might be poor pin wetting if it does not toggle (1/0) plugging cable for device mode. Ralf can confirm this but not all SW checks for USB power bit set such as when USB is in Host mode.

This register indicate the USB has +5v VBUS:

0x001    USBPOWER      USB Power 

This register indicate the USB interrupt is enabled:

0x00B USBIE USB Interrupt Enable

When I used CCS XDC to debug usb_dev_cserial, there is no bootloader. When USBDCompositeInit is called, USBP0 will go high for good IC, but the bad one's USBP0 stays low

I have no desire to debug into TI's library

Anyway, after I replaced the IC, everything works

David Chance said:

When I used CCS XDC to debug usb_dev_cserial, there is no bootloader.

That is a moot point anyway. Again, there is no such signal USBP0 defined in the TM4C1294 datasheet signal table 21-1. You might check the MCU pulled for ABA to test VBUS pin 96 (PB1) impedance to GND pin on the same side.

David Chance said:

Anyway, after I replaced the IC, everything works

Yet you still don't know what lead to MCU failure of USB port. There is a workaround for bad VBUS pin if it is not to badly shorted roughly >300Ω.