USB Controller on TM4C129ENCPDTI3 randomly switches from Full Speed to High Speed mode

Hello Bill,

Is it possible for you to reproduce the problem in a standalone Tiva Setup so that then we can migrate over the code for analysis?

Regards

Amit

Amit,

    After a bit more investigating, we tracked it down to the BABBLE interrupt getting generated.   In the usbhostenum.c file, the interrupt handler function -> USBHostIntHandlerInternal()  checks for the BABBLE  interrupt - but it appears not do anything about it :-(        So the code would hang in the while loops in the sending functions in the usbhostenum.c functions.

So my question is there a way we can lower any USB timing registers?  Or how can we best handle the BABBLE condition with the TI library functions?  Is there a soft USB reset function we can call when this condition occurs? 

Thanks,

Bill

Amit,

      We have also found we can consistently replicate the condition now by using a stun gun (generating ESD) near the USB cable (about an inch away) and we always get the BABBLE interrupt, then the USB registers show its switched from Host to Device and Full Speed to High Speed.

I'd still like to get your insight on how to handle the BABBLE interrupt or if there are any USB registers values that are worth changing.

Thanks,

Bill

Hello Bill,

A Babble would indicate that the bit patterns on the USB DP-DM are not correct for the transaction. In such a case a soft reset can be done followed by USB Stack Initialization. The Soft Reset is handled by the SysCtlPeripheralReset API Call.

Regards

Amit

Thanks Amit.  So is having BABBLE randomly occur a "Bad" thing?  I did notice in the TI USB stack that they do not handle BABBLE events.  So maybe this is something that typically should not happen?  Just curious why its not handled?

Also when you mention USB Stack Initialization - do you mean the complete USB initialization?  Such as calling  USBStackModeSet(), USBHCDRegisterDrivers(), USBHCDInit(), etc... ?

Thanks,

Bill

Hello Bill,

Yes. A babble condition on the USB Bus means that the downstream device may be not working well (even if it is due to the noise being induced). The USB specification is very vague when it comes to handling babble. But one thing it does mention is disabling the port and then attempting to restart the port.

Regards

Amit

Hello Bill,

Bill Sousan said:

After a bit more investigating, we tracked it down to the BABBLE interrupt getting generated.
So my question is there a way we can lower any USB timing registers?

Sound like the USB bit clock of the target printer is relatively slower than the TM4C host, more than standard tolerance.

You may increase the value of this register, so that the last transaction wouldn’t overlap the next SOF timing - ie. babble.

USBFSEOF (offset 0x07D) - "USB Full-Speed Last Transaction to End of Frame Timing" register

Using this value, the host controller determines if it could start a transaction near the end of frame, or not. Increasing this value, your host could escape from babble.

The reset value of this register is 0x77, which means 63.46 us (= 768 bit clock)
The unit is 533.3 ns (= 6.4 bit clock)

As the TivaWare doesn’t touch to this register at all, it should keep the reset value.
You may put this code just after the host initialization.

#include "inc/hw_memmap.h"
#include "inc/hw_usb.h"

USBHCDInit(0, g_pHCDPool, HCD_MEMORY_SIZE);
HWREGB(USB0_BASE + USB_O_FSEOF) = 0x77 + alpha;  // <--------

If you would have a hardware bus analyzer, you could estimate the increment by catching the babble event. If you don’t have it, titrate the value by reproducing the error.

As I said first, babble occurs when the USB bit clock of the target is relatively slower than your host. If the clock frequency of your host would be too higher than the standard, it should also result in babble.
- For USB host operation, a crystal OSC is required, instead of inaccurate internal OSC.
- unstable oscillation also causes babble.

Bill Sousan said:

We have also found we can consistently replicate the condition now by using a stun gun (generating ESD) near the USB cable (about an inch away) and we always get the BABBLE interrupt,

Surge on USB line often contaminates into the power rail of the board, and it could make the OSC unstable. Attach a TVS diode across VDD - GND at the USB receptacle of your host. A ferrite bead, too.

Tsuneo