EK-TM4C1294XL: USB stack VBUS/ID INT58 NDA

Part Number:EK-TM4C1294XL

What is the point of top secret handling USB datasheet information when design engineers have to pay an yearly fee to redistribute USB anyway? Frankly after dealing with all the issues of data transport handling misinformation, interrupt failures and other random crashes it seems an futile attempt by the USB authority to continue that practice. Not withstanding how some past TI engineers had interpreted the USB protocol for device handling leave me believing they were/got confused. That can be seen when USB peripheral VBUS pin is shorted out from high current flow plugging cable in and a 1uf MIN cap is not present on the input. Perhaps with good reason any capacitor value added to the VBUS pin seems to inflict the droop detection register area of the peripheral even when it is not being used in device mode.

Part of the problems I have been dealing with "to be nice" revolve around (usb.c) handling of 3 different device modes (device, host, OTG). Between (usbdenum.c) attempts to confuse handling, hardware controls of VBUS/ID pins and NDA datasheet missing register BIT clarifications any real attempt to have USB (rapidly) remarketed for Windows client use seem futile. Another key area USB0_INT58 interrupt handing of register USBIE (interrupt enable) and software failing to clear the NVIC global interrupt specified in (startup_ccs.c) or registered anywhere in code. It really doesn't matter since USB0_INT58 is not working in device mode and may have issues in other modes, IDK! However USB0_INT58 is not being properly cleared, unpend seems next best way absent any INTClearUSB0().

That said I have reviewed the handling of device mode VBUS/ID pins was confused by several calls, according to foot notes written in device defines of the three modes handling of USB/ID pins.

The handling of USB stack passed variable and how (usbdenum.c) determines the modes after updating (usb.c) to match verbatim, below. There seems one call missing (usb.c) to force device mode, added into (usbdenum.c) handling of USBStackModeSet(). No wonder I was so confused when the VBUS pin had eventually shorted out from high current after plugging USB cable 100's of times into host computer. Passing the variable eUSBForceDevice had no effect on USB_O_GPCS since it was absent.

        //
        // Force VBUS/ID high, device mode if requested.
        //
        if(g_iUSBMode == eUSBModeForceDevice)
        {
            //MAP_USBDevMode(USB0_BASE);
            HWREG(USB0_BASE + USB_O_GPCS) |= USB_GPCS_DEVMOD_DEV;
        }
        else if(g_iUSBMode == eUSBModeOTG)
        {
            //
            // To run in active device mode the OTG signals must be active.
            // This allows disconnect to be detected by the controller.
            //
            MAP_USBOTGMode(USB0_BASE);
        }
        else
        {
            //
            // In all other cases, set the mode to device this function should not
            // be called in OTG mode. Active monitor VBUS and ID must pull high.
            //
            g_iUSBMode = eUSBModeDevice;
            MAP_USBDevMode(USB0_BASE);
        }

//*****************************************************************************
void
USB0DeviceIntHandler(void)
{
    static uint32_t ui32Status;

    /* Unpend the USB global NVIC interrupt */
    IntPendClear(58);

    //
    // Get the controller interrupt status.
    //
    ui32Status = MAP_USBIntStatusControl(USB0_BASE);

    //
    // Call the internal handler.
    //
    USBDeviceIntHandlerInternal(0, ui32Status);
}