TM4C1294KCPDT: USB0 OTG device suspend VBUS pin

Hello BP101,

Tracking what you are describing via just stack debug is challenging, can you get a USB analyzer on the USB port so we can see the actual communication that is occurring on the USB lines? Then we will be able to see whether or not the suspend is occurring and any possible packets that are not being handled correctly. With that info in hand, it's much easier to trace down any issues with the application itself.

Hi Ralph,

I have ICDI debug console printing UART debug messages hot from inside the USB interrupt handler which never prints during suspend events, SOF or any other event. I added static to the status message return variable used to determine the interrupt HW source.  Have not had chance to test it yet and separate the three RX event messages with breaks that points to power fault status message. Not to surprising since the VBUS pin is being monitored for current flow even with self powered device configured.  This same interrupt handler has never worked correctly in any version of USB library! USB link suggest the keep alive should be sending SOF frames at 1ms +/-500ns which is not configured in bulk device software. Therefore Suspend/Resume hardware interrupts must fill that keep alive void during 3ms bus idle times as I see it. That often occurs during PWM0 excessive activity when he has higher interrupt priority than USB0!   

Seemingly endpoint idle issue is hardware related with self power device since the USB device client transfers occur in 1 second intervals, suspend is expected without keep alive. I don't have USB analyzer to check why the interrupts status are not being returned or detected by USB0 peripheral but the composite event is always being passed to RxEvent handler. The hardware interrupt status code is redundant since it checks Control EP0 status twice for unknown reasons.

Bulk interrupt handler code snips: Note ui32Status EP0 is redundant from that of similar status prior returned via USB0DeviceIntHandler() and derived via USBIntStausControl() (usb.c)...

uint32_t
USBIntStatusControl(uint32_t ui32Base)
{
    static uint32_t ui32Status;

    //
    // Check the arguments.
    //
    ASSERT(ui32Base == USB0_BASE);

    //
    // Get the general interrupt status, these bits go into the upper 8 bits (How exactly is << shift occurring????) 
    // of the returned value.
    //
    ui32Status = HWREGB(ui32Base + USB_O_IS)

void
USBDeviceIntHandlerInternal(uint32_t ui32Index, uint32_t ui32Status)
{
    static uint32_t ui32SOFDivide = 0;
    void *pvInstance;
    uint32_t ui32DMAIntStatus;
    uint32_t ui32LPMStatus;
    //
    // Suspend was signaled on the bus.
    //
    if(ui32Status & USB_INTCTRL_SUSPEND)
    {
        UARTprintf("INT Status USB0 Suspend (usbdenum.c) \n");
        //
        // Call the SuspendHandler() if it was specified.
        //
        if(g_ppsDevInfo[0]->psCallbacks->pfnSuspendHandler)
        {
            g_ppsDevInfo[0]->psCallbacks->pfnSuspendHandler(pvInstance);
        }
    }

    //
    // Resume was signaled on the bus.
    //
    if(ui32Status & USB_INTCTRL_RESUME)
    {
        UARTprintf("INT Status USB0 Resume (usbdenum.c) \n");
        //
        // Call the ResumeHandler() if it was specified.
        //
        if(g_ppsDevInfo[0]->psCallbacks->pfnResumeHandler)
        {
            g_ppsDevInfo[0]->psCallbacks->pfnResumeHandler(pvInstance);
        }
    }

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

    //
    // Handle end point 0 interrupts.
    //
    if(ui32Status & USB_INTEP_0)
    {
        USBDeviceEnumHandler(&g_psDCDInst[0]);
        ui32Status &= ~USB_INTEP_0;
    }

USB analyzer report after re-plugging USB cable to clear EP1 client for random SUSPEND event on host end. The host side client must be closed/opened each time the exception handler posts fault. 

Hi Ralph,

I don't think this issue is power related as the returned event code does not qualify for any of the power defines (above post). Yet the idle status interrupt handler is not producing keep alive frames per USB documented Suspend status handling in the absence of ~OUT_PKTRDY. Hence a false Suspend state event can occur without Automatic recovery for the suspended client on host side of connection. The client will indeed quickly choke and post an exception flag as it now does. How might this interrupt status call be corrected to stop a false Suspend from occurring? Does the USB controller design compensate for false idle suspend by sending keep alive frames (SOF) to the OUT endpoint?

Otherwise the USBDCDInfoInit() (call snip below) was forcing Boolean Self/Bus power state flag to FALSE no matter if a call to USBDCDPowerStatusSet() had previously been invoked. Seemingly smarter logic will query for the correct Bool flag rather than force perhaps incorrect power state status upon an assumed application.    

        //
        // In the IDLE state the code is waiting to receive data from the host.
        // Code needs to send empty frame keep alive until packet is ready!
        // USB has a start of frame packet or keep alive sent periodically on the bus.
        // This prevents an idle bus from entering suspend mode in the absence of data.
        //• A high speed bus will have micro-frames sent every 125.0 µs ±62.5 ns.
        //• A full speed bus will have a frame sent down each 1.000 ms ±500 ns.

        case eUSBStateIdle:
        {
            //
            // Is there a packet waiting for us?
            //
            if(ui32EPStatus & USB_DEV_EP0_OUT_PKTRDY)
            {
                //
                // Yes - process it.
                //
                USBDReadAndDispatchRequest(0);
            }
            break;
        }

   //
    // Determine the self- or bus-powered state based on the flags the
    // user provided via call to USBDCDPowerStatusSet();
    //
    g_psDCDInst[0].bPwrSrcSet = g_psDCDInst[0].bPwrSrcSet; 

 

Hello BP101,

The issue you are describing with suspend is not one we have come across and using UART outputs for debug is not sufficient data for me to be able to act on. You need to get a USB analyzer and send me a USB analyzer capture of the USB lines so I can see the packets, timings, and error bytes being identified etc.

Once that is in hand, it will be more feasible to try and uncover what portion of your setup may be the cause of the behavior.

Hi Ralph,

Yet as you can see Suspend interrupt is not being triggered from Host packets nor is the Suspend interrupt ever triggered. You have evaded my question USB 2.0 standard requires keep alive frames to Thwart off rouge Suspend events during packet idle time. The idle event handler makes no such attempt to maintain USB2.0 Suspend compliance. It is only logical to deduce the USB library omits keep alive SOF but why? Does the PHY automatically produce the necessary keep alive frames during idle packet transfers?

That said a USB analyzer will not reveal reason for library posting rouge Suspend Events as PWM occupies NVIC higher priority status. I suspect the 1.5k pull up on D+ is triggering a USB peripheral register outside of Tivaware USB library control! Otherwise the only way a Suspend event can occur is if VBUS pin current exceed 500mA/2, default for Self Powered devices. I removed VBUS/ID pins Micro port connections PHY control and the same Suspend events occur.

We must ask how can a USB peripheral Suspend event occur if not by the Suspend interrupt handler shown above? The only logical answer is the idle handler to blame. Other scenario host may send Suspend notice to EP1 triggered only via USB interrupt which never occurs.

Hi Ralph,

Handshake USB2.0 standard transmit SOF frames in 1ms intervals and or NAK the device host during idle time, NVIC other peripheral interrupts. That function is not occurring by USB library handling EP0 (case eUSBStateIdle:) when NVIC is servicing higher priority interrupts such as PWM0.

Later suspend events are seemingly being triggered (internally) by the USB0 controller. It is not the device client host signaling Suspend or the Suspend interrupt would be occurring just before the events occur.  Fact is a USB protocol analyzer can not debug internal USB0 registers or interrupts.

Again all other UARTprintf() occur, prints several Suspend events simply plugging USB cable and several more when PWM0 is running. Clearly EP0 is not issuing NAK to the device host during plugging or idle and internal several suspend events occur. Otherwise Suspend events should never occur without Resume shortly following. You have not explained why Resume never occurs after several Suspend events before the EP1 device client has been launched. Seemingly the DCD device driver is also failing to Stall/NAK EP1 until the endpoint client has launched. Could be where several repeating Suspends also occur plugging cable during PWM0 higher priority interrupts.

Start of Frame Packets:

The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus.

Hello BP101,

I agree the analyzer won't debug the internally but I need that to even begin investigation. This issue has never come up before and I have no background to reference from other customers who came across it, so as I have to start from scratch I need the USB analyzer data to even begin to look into this. I cannot answer the question about the Resume not following without seeing USB data. This is like asking me why a SPI slave didn't respond without being able to scope the SPI lines to see what actually is occurring! I can't know if packets were dropped, not sent, what the last packet issued was etc. without that information!!

Until I have a USB analyzer shot, I cannot help you with this issue.

Hi Ralph,

Sometimes the answer is staring us right in the face and has been presented this forum for 2 years or more without a solution.  Again what you should be asking is how on earth is the Resume event being triggered from the embedded USB library without interrupt events triggering. Suspend as I have stated several times you can see from UARTprintF occurs simply plugging in the cable. This same exact issue has always existed in the BULK device example but was not being printed. TI engineers were clueless USB device mode has OTG power issues and Tivaware has not configured nor is monitoring USB0PEN / USB0PFLT0 (PL6/PL7) respectively. The USB controller has other ideas about how OTG device mode operates contrary to datasheet and Tivaware configuration comments.

The random pipe disconnect condition is not a result of data transfer, though it often occurs during internal Suspend event. It is obvious that embedded USB library parts are reacting to the peripheral during initialization and when VBUS current level is being incorrectly detected by OTG registers. Suspend clues runs contrary to how Tivaware device calls control USBEPC, USBEPCISC, USBVDC registers, or not at all.

Likewise Suspend issue is more classified being undisclosed OTG internal device errata. I say errata since discovering any or no capacitance on VBUS pin changes failure frequency no matter what device mode VBUS/ID pins are configured and control descriptor 200mA count increased. The problem is known since there is a SW filter correction but should not be needed by a SELF_POWERED_DEVICE or USBOTGMode configured VBUS pins. The clues are posted, the USB controller expects OTG device (pins/registers) be configured beyond bulk device example or Tivaware calls that claim being valid for Host mode only configurations.  

I previously posted the event callback modify to post Suspend prints so you can easily see the same issue easy as pie.

 

Hello BP101,

I think you need to spend some time to review how USB operation is supposed to occur. Generating a Host Endpoint for a USB Device is not a solution to your problem, and we certainly would never consider adding such a contradictory piece of code into our USB library that 100's of customers are using without hitting the issue seen on your system setup.

There is no 'unknown default host endpoint', because the TivaWare USB Device mode handling does not use HOST endpoints.

If you are seeing an improvement, then that means you are likely missing another USB Device API call in your configuration which is called by the Host Endpoint Configuration API. So I would suggest you check what is done within USBHostEndpointConfig, and see what impacts VBUS and USB power settings, and then go through your initialization code and ensure you actually are making all the required calls to set the right registers.

Ralph Jacobi said:

There is no 'unknown default host endpoint', because the TivaWare USB Device mode handling does not use HOST endpoints.

You would be wrong about any Control end point being required when it most certainly is needed to establish a properly configured control end point 0. From the perspective of the device client connection IN/OUT end pipes it is a host control Message endpoint, never configured. Again NAK frame delays are required during idle bus time to stop Suspend from occurring and the (usbdenum.c) as it existed was NOT set up to handle any such function for high speed EP0 signaling.

Anyway it did not reveal a hidden default Control EP0 configuration, in my mind it therefore did not exist! Perhaps you should take the time to test the bulk device example with more than keyboard echo signal rates, it is only a generic example. The point of an MCU to bundle multiple peripherals sharing the AHB and higher priority peripherals take larger time slices away from USB0. Datasheet makes no attempt to suggest how the USB library handling of NVIC Interrupts may require any specific CPU priority without explicit modification to Example software being required order to achieve sustain USB2.0 message/stream packet transfer rates. 

Ralph Jacobi said:

If you are seeing an improvement, then that means you are likely missing another USB Device API call in your configuration which is called by the Host Endpoint Configuration API

TI engineers wrote the device example using UNKNOWN default control endpoint 0 configuration. Agree the missing call to properly configure EP0 is now added to the device client as above post shows! Perhaps you too need to review how USB 2.0 operation is supposed to occur. 

https://en.wikipedia.org/wiki/USB#Further_reading

Bulk transfers: Large sporadic transfers using all remaining available bandwidth, but with no guarantees on bandwidth or latency (e.g., file transfers)

When a host starts a data transfer, it sends a TOKEN packet containing an endpoint specified with a tuple of (device_address, endpoint_number). If the transfer is from the host to the endpoint, the host sends an OUT packet (a specialization of a TOKEN packet) with the desired device address and endpoint number. If the data transfer is from the device to the host, the host sends an IN packet instead. If the destination endpoint is a uni-directional endpoint whose manufacturer's designated direction does not match the TOKEN packet (e.g. the manufacturer's designated direction is IN while the TOKEN packet is an OUT packet), the TOKEN packet is ignored. Otherwise, it is accepted and the data transaction can start. A bi-directional endpoint, on the other hand, accepts both IN and OUT packets.

Hello BP101,

Once again I am not sure where you get these ideas from.

EP0 is properly configured within the USB stack via the handler.

The function call chain is USB0DeviceIntHandler (in startup_ccs.c) -> USBDeviceIntHandlerInternal (usbdenum.c) -> USBDeviceEnumHandler (usbdenum.c)

The last function has the following states:

        //
        // Data is still being sent to the host so handle this in the
        // EP0StateTx() function.
        //
        case eUSBStateTx:
        {
            USBDEP0StateTx(0);
            break;
        }

        //
        // We are still in the middle of sending the configuration descriptor
        // so handle this in the EP0StateTxConfig() function.
        //
        case eUSBStateTxConfig:
        {
            USBDEP0StateTxConfig(0);
            break;
        }

The second is the configuration for EP0.

If EP0 didn't work, we'd have 100's of upset customers because as you identified, it is essential for your application.

You should make sure your TivaWare USB library follows the outlined call hierarchy, because if it doesn't then perhaps you changed something in a way that is causing your issue. But if it does, then EP0 is being created and you need to follow my advice and get a USB analyzer to actually see the communication and realize that EP0 is working functionally.

Hi Ralph,

Oddly the above text blue highlight (NutShell) states Bulk control endpoint is required for EP0. Perhaps EP0 is better configured first inside USBDCDInit() and is seemingly not being fully configured in USBDEP0StateTx(), I will debug confirm interrupt actually occurs. Like EP0 works with limited control but again had issues, idle timeout Suspend when USB0 did not randomly have AHB priority status. It seems better to configure the USB peripheral registers, USBHostEndpointConfig() directly configures them. The EP0 is much more stable after register changes even as I had reversed NAK millisecond timeout value with Target endpoint 0. Go figure. 

More info below: 1023 byte bulk data packets discussion (Full Speed) mode contradicts device descriptor text, 512 byte packets (NutShell). Lot of Google chatter since USB3.0 emerged about these two speeds and bulk packet sizes USB2.0.

Data Packets:

There are two types of data packets each capable of transmitting up to 1024 bytes of data.

◾Data0

◾Data1

High Speed mode defines another two data PIDs, DATA2 and MDATA.

Data packets have the following format,

Sync PID Data CRC16 EOP

◾Maximum data payload size for low-speed devices is 8 bytes.

◾Maximum data payload size for full-speed devices is 1023 bytes.

◾Maximum data payload size for high-speed devices is 1024 bytes.

◾Data must be sent in multiples of bytes.

Have confirmed (eUSBModeDevice , eUSBModeForceDevice) modes also fail to Set Disconnect interrupt and all other (assumed) masked interrupts never occur. Again assumed INTS are masked by call below, and the USBPOWER register indicates VBUS toggles when cable is being plugged in/out. Yet the Disconnect INT never triggers nor do any of the other Masked INTS ever change state. This issue involes USB controller MODE detect failure, VBUS/ID pin state should also trigger HW disconnect masked interrupts but fails to do so. That is if they are being masked at all or the ID pin interrupt valid interrupt somehow constrains the other interrupt sources?

Therefore RESUME never occurs after SUSPEND and NAK timeout may randomly occur, All SET interrupt events should trigger USB library HW interrupt handler calls but never do.

        //
        // Enable USB Interrupts.
        //
        MAP_USBIntEnableControl(USB0_BASE, USB_INTCTRL_RESET |
                                           USB_INTCTRL_DISCONNECT|
                                           USB_INTCTRL_RESUME |
                                           USB_INTCTRL_SUSPEND |
                                           USB_INTCTRL_SOF); 

void
USBIntEnableControl(uint32_t ui32Base, uint32_t ui32Flags)
{
    //
    // Check the arguments.
    //
    ASSERT(ui32Base == USB0_BASE);
    ASSERT((ui32Flags & (~USB_INTCTRL_ALL)) == 0);

    //
    // If any general interrupts were enabled, then write the general
    // interrupt settings out to the hardware.
    //
    if(ui32Flags & USB_INTCTRL_STATUS)
    {
        HWREGB(ui32Base + USB_O_IE) |= ui32Flags;
    }

    //
    // Enable the ID pin detect interrupt.
    //
    if(ui32Flags & USB_INTCTRL_MODE_DETECT)
    {
        HWREG(USB0_BASE + USB_O_IDVIM) = USB_IDVIM_ID;
    }

Where is USBIntClear() for NVIC global interrupt 58. Startup_ccs.c -> USB0DeviceIntHandler() is not RTOS? Seemingly interrupt source IntEnable() followed by USBIntClear() which does not exist. Even as originally coded RTOS semaphore (OS_INT_ENABLE) the interrupts were not being triggered, perhaps once only during Reset but never again. To make USB0 a Global Semaphore CMIS triggered interrupt source the call is shown below IntEnable(). Lets hope it works and we don't have to make periodic calls USBOTGMain() to get polling interval to set/service USB interrupt sources.

The test reveals INT58 is never triggered any way it has been configured (SW/HW). Yet  VBUS toggles Low removing cable from Micro-B, disconnect interrupt status never occurs. That sort of confirms Suspend, Resume, SOF interrupt status are MIA too. I'd expect the disconnect interrupt status at a minimum level of functionality of EP1 composite interface capability.

 

//
// Enable the USB interrupt.
//
//OS_INT_ENABLE(g_psDCDInst[0].ui32IntNum)
  MAP_IntEnable(INT_USB0);

// Enable USB0 Global NVIC interrupt source Semaphore
// Trigger an Software, CMIS interrupt. 

HWREG(NVIC_SW_TRIG) = INT_USB0 - 16;

Hello BP101,

Can you outline the test you did, and also try it on our LaunchPad? If you can re-create this supposed non-firing interrupt with a TivaWare example perhaps I can look into more and explain what you are seeing because the interrupt definitely fires for our examples so perhaps it's an issue with your debug method that is resulting in your not seeing it on your hardware.

Still awaiting USB analyzer capture for the Resume/Suspend issue.