TM4C1294KCPDT: Disabled USB0 analog VBUS/ID pins

Hi Charles,

It would seem USBGPCS is not changing per say as the target interface link into PC (CDC) remains connected after client posts an exception. The bulk device client exception reports an error occurred in the RX pipe after perhaps disconnecting the endpoint?

The USB tick timer call to 7 established endpoints seemingly fails to scan USBGPCS register during missed tick cycles.  So tick timer thinks the client initiated an endpoint disconnect when it did not. Typically USB endpoints teardown of remote pipes would occur had the USB cable been unplugged from target or host. The debug watch USB0 connection status (UARRTprintf()) never reports disconnect/connect unless we physically remove USB cable from port.  That toggles the VBUS/ID pin polarity or being forced high via USBGPCS register when analog GIPO PB1, PB2 are disabled. So the same endpoint exception failure is occurring either way USBGPCS is being updated or configured.

Oddly there are only 6 tick handlers configured for 7 bulk endpoints, perhaps uDMA transfers of end point pipe data are not emptying ring buffers fast enough during times of heavy AHB traffic. Sometimes the pipe exception on Windows bulk client happens immediately. Other times of heavy AHB traffic bulk data transfers of several IOT variable print status lasts for a few report cycles then crashes. The only way to fix the target bulk device end points requires re-plug USB cable and re-starting the device client. The target should automatically rebuild the disconnected pipe since the USBGPCS never indicated USB cable being unplugged from target. Seemingly the 7 endpoints linked to CDC low level driver should always be refreshing as part of target endpoint pipe links via tick handlers and cyclic USB library calls. This might even be the bulk device windows client to blame but pipe disconnect seems to be initiated from the target.

bool
USBDeviceConfig(tDCDInstance *psDevInst, const tConfigHeader *psConfig)
{
    uint32_t ui32Loop, ui32Count, ui32NumInterfaces, ui32EpIndex, ui32EpType,
             ui32MaxPkt, ui32NumEndpoints, ui32Flags, ui32BytesUsed,
             ui32Section;
    tInterfaceDescriptor *psInterface;
    tEndpointDescriptor *psEndpoint;
    tUSBEndpointInfo psEPInfo[NUM_USB_EP - 1];//NUM_USB_EP = 8

    //
    // How many (total) endpoints does this configuration describe?
    //
    ui32NumEndpoints = USBDCDConfigDescGetNum(psConfig,
                                              USB_DTYPE_ENDPOINT);
}

//*****************************************************************************
//
// This internal function initializes the variables used in processing timer
// ticks.
//
// This function should only be called from within the USB library.  It is set
// up to ensure that it can be called multiple times if necessary without
// the previous configuration being erased (to cater for OTG mode switching).
//
// \return None.
//
//*****************************************************************************
void
InternalUSBTickInit(void)
{
    uint32_t ui32Loop;

    if(!g_bUSBTimerInitialized)
    {
        for(ui32Loop = 0; ui32Loop < MAX_USB_TICK_HANDLERS; ui32Loop++)
        {
            g_pfnTickHandlers[ui32Loop] = (tUSBTickHandler)0;
            g_pvTickInstance[ui32Loop] = 0;
        }

        g_bUSBTimerInitialized = true;
    }
}

And another find related to module timing under the USB hood may relate to service intervals being interrupted by higher priority peripherals (PWM, ADC0) that have CPU's undivided attention.

//*****************************************************************************
//
// usblibpriv.h - Private header file used to share internal variables and
//                function prototypes between the various modules in the USB
//                library.  This header MUST NOT be used by application code.

//*****************************************************************************
//
// Internal interrupt handlers called from the main vectors in device and
// host mode.
//
//*****************************************************************************
extern void USBDeviceIntHandlerInternal(uint32_t ui32Index,
                                        uint32_t ui32Status);
extern void USBHostIntHandlerInternal(uint32_t ui32Index, uint32_t ui32Status);

//*****************************************************************************
//
// The maximum number of tick handlers that can be registered in a system.
//
//*****************************************************************************
#define MAX_USB_TICK_HANDLERS       6

//*****************************************************************************
//
// This value defines the number of SOF ticks that must pass before a call
// is made to InternalUSBStartOfFrameTick.  The value 5 ensures that the
// function is called every 5 milliseconds assuming that SOF interrupts are
// enabled and SOF is present.
//
//*****************************************************************************
#define USB_SOF_TICK_DIVIDE 5

Hi Ralph,

I think the datasheet is not being specific for typical USB single point connections, rather makes a blanket statement to achieve 480 MBPS transfer speed with external PHY (HUB) requires 60mHz clock rate. It is impossible to achieve 480 MBPS packet transfers to an end point, so the external PHY bus speed is my take on what the text is referring to. Hope NDA USB PDF has a better perspective on this requirement.

At lest at 16mHz USB clock with 25Mhz MOSC the target is not randomly trashing the end pipe of the host device. Seemingly something ain't exactly right in the USB library management of buffer full status handling as it can quickly crash the end pipe by flooding it with high speed data transfers even at 16mHz. Below is a threshold test after packet transfers are complete checking the ring buffer space is not <128 bytes. Disabling the buffer check results in quickly trashing the end pipe client via non-interrupted packet transfers. Typically the application processes 64 byte packet transfers in 1 second intervals to the bulk device. So that is not as volatile as doing non-interrupted packet transfers to the bulk device client. Even the 1 second intervals seemed to rapidly fill the buffer from blocked USB Status updates when the AHB gets real busy at times with higher priority NVIC INT pends.  

//*****************************************************************************
uint32_t
TxHandler(void *pvCBData, uint32_t ui32Event, uint32_t ui32MsgValue,
          void *pvMsgData)
{
    uint32_t ui32Space;
    //
    // We are not required to do anything in response to any transmit event
    // in this example. All we do is update our transmit counter.
    //
    if(ui32Event == USB_EVENT_TX_COMPLETE)
    {
        //
        // How much space is there in the transmit buffer?
        //
         ui32Space = USBBufferSpaceAvailable(&g_sTxBuffer);

        if(ui32Space < 128)
        {
          /* Flush the TX buffer of any overflow data */
          USBBufferFlush(&g_sTxBuffer);
        }

        g_ui32TxCount += ui32MsgValue;
    }
    return(0);
}

Hello BP101,

BP101 said:

Seemingly something ain't exactly right in the USB library management of buffer full status handling as it can quickly crash the end pipe by flooding it with high speed data transfers even at 16mHz.

Are you truly using high speed mode, or just full speed? Not many use High Speed mode. If you are using High Speed, check if applying the following bug fix helps: e2e.ti.com/.../2518648

BP101 said:

Below is a threshold test after packet transfers are complete checking the ring buffer space is not <128 bytes. Disabling the buffer check results in quickly trashing the end pipe client via non-interrupted packet transfers.

I am not sure what you are trying to prove here, of course disabling the buffer check is going to mess things up. If it wasn't needed, it wouldn't be there in the first place.

Hi Ralph,

From my understanding the bulk device driver is in high speed mode is being set during USB0 initialization.

The buffer status was added by me, the USB library is supposed to handle the buffer space status callback but it does not do a very good job when doing direct calls to USBBufferWrite() via the (usb_bulk_structs.c) typedef struct defined buffers size.

Hi Ralph,

Ralph Jacobi said:

USB High Speed is not that simple... you need an external High Speed USB PHY to use High Speed with the device, and then have to toggle on software that High Speed is being used.

Perhaps device mode defaults to FS since the ULPI feature is never set (usb_dev_bulk.c) call to USBBulkInit() call to USBDCDIniti(). Below it looks like speed actually defaults to FS if the ULPI feature mode is never configured?

usbdenum.c --> USBDCDInit()

        //
        // Configure ULPI support.
        //
        if(g_ui32ULPISupport != USBLIB_FEATURE_ULPI_NONE) //NONE=0x0000.0000
        {
            USBULPIEnable(USB0_BASE);

            if(g_ui32ULPISupport & USBLIB_FEATURE_ULPI_HS)
            {
                ULPIConfigSet(USB0_BASE, ULPI_CFG_HS);
            }
            else
            {
                ULPIConfigSet(USB0_BASE, ULPI_CFG_FS);
            }
        }
        else
        {
            USBULPIDisable(USB0_BASE);
        }