Handling babble interrupt on TM4C1294

Hello Amit,

I am having similar issues to that of Peter’s where the USB switches from host to device. I have actually noticed a couple of threads on e2e with similar issues. I am using a Tiva Tm4c129ENCPDT on a development board which is used as a host only. I tried forcing the USB stack to host only using USBStackModeSet(0,eUSBModeForceHost,0). I also tried placing a hardware watch point on the USB_DEVCTL register and can’t seem to trace when USB_DEVCTL_DEV bit is being set.  I can see the USB_DEVCTL_SESSION bit is being set in the USBOTGSessionRequest. Here are a couple of questions I have:

-Where is USB_DEVCTL_DEV bit being set?

-Should the babble interrupt be handled in TI drivers?

-If the babble interrupt is to be handled by the user, how do you recommend re-initializing the driver and USB stack when sometimes the babble causes us to be stuck in while loop in TI drivers (USBHCDControlTransfer)?

Thanks,

Ismail

Hi Amit,

The USB peripheral has already resetted this way (case eHCDVBUSError in usbhostneum.c, as babble error sets g_sUSBHCD.ui32IntEvents = INT_EVENT_VBUS_ERR):

            MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_USB0);

            //
            // Wait for 100ms before trying to re-power the device.
            //
            OS_DELAY(g_ui32Tickms * 100);

            //
            // Re-initialize the HCD.
            //
            USBHCDInitInternal(0, g_sUSBHCD.pvPool, g_sUSBHCD.ui32PoolSize);

Is this the correct way to reset the USB controller? I tried to add these lines before resetting:

            MAP_SysCtlPeripheralDisable(SYSCTL_PERIPH_USB0);
            OS_DELAY(g_ui32Tickms * 100);
            MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);

But it does not help: no USB communication, no USB interrupts are generated and the USB_DEVCTL is still 0x81 (DEV=1, SESSION=1).

Best regards,

Peter

Hello Amit,

I've tried the above code, but it does not help. And I experienced worrying things: after the babble interrupt occurred I disconnected/connected the USB hub from the development board a few times and the MCU was getting extremely hot in a few seconds. I disconnected the power of development board. What happened?

Best regards,

Peter

Edit: I zipped the edited mouse example and usblib. I uploaded: tiva_ek-tm4c1294xl_usb_host.zip

Amit,

I was able to recover from the USB being switched to device. I had a higher priority task periodically check the USB_DEVCTL register; once the right conditions were met I would reset the USB peripheral. It seems to be working, however, I am using USBMSCHFatFs and that doesn't seem to fully recover every time. Sometimes I would perform a block read and get stuck in the USBHCDPipeRead while(1) loop. Here is what I do when I detect a babble:

USBMSCHFatFs_close(usbmschfatfsHandle);
SysCtlPeripheralDisable(SYSCTL_PERIPH_USB0);
SysCtlPeripheralReset(SYSCTL_PERIPH_USB0);
SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);
usbmschfatfsParams.servicePriority = 5;
usbmschfatfsHandle = USBMSCHFatFs_open(USBMSCHFatFs0, 0, &usbmschfatfsParams);
USBStackModeSet(0,eUSBModeForceHost,0);

Thanks,

Ismail

Hi Amit,

Sometimes 10 connect/disconnect sometimes 100 connect/disconnect needed to get the error. I've got a simple device which can disconnect the 4 wires of USB using a relay. Of course that relay device is not essential, it just makes easier to reproduce the problem.
The devices are connected this way: EK-TM4C1294XL <- Beagle USB 480 <- USB HUB <- relay device <- USB mouse.

It looks that type of USB hub is important: the babble error occurs with Trust HU-1240Tp HUB (full speed) and with other noname FS hub.

Best regards,

Peter

Amit,

I do think e2e is very useful. I think I am coming closer to a solution. I read the link you suggested. They seem to be having similar issues but not quite the same. I don’t have the INT_EVENT_DISCONNECT problem I am mainly stuck in the “interior while loop” only. I have the g_sUSBHCD.psUSBINPipes[ui32PipeIdx].iState = ePipeReadDMA and it is not switching to ePipeDataReady. ui32RemainingBytes is equal to ui32BytesRead. Should I have this question in a different thread?

Thanks,

Ismail

Amit,

 The problem is when there is an updated version of the driver I would have to rebuild that aswell. If its an issue I can resolve on the application side that would be better or maybe it is bug and the fix can be included in future driver releases. Either ways I need some direction in figuring out the source of the problem. Why is g_sUSBHCD.psUSBINPipes[ui32PipeIdx].iState not being set to ePipeDataReady.

Thanks,

Ismail

Amit,

I made the changes you suggested and I seem to get stuck in PipeRead instead. Here are the changes I made:

if(ui32Status & USB_INTCTRL_CONNECT)
    {
        //
        // Set the connect flag and clear disconnect if it happens to be set.
        //
        g_sUSBHCD.ui32IntEvents |= INT_EVENT_CONNECT;
       //g_sUSBHCD.ui32IntEvents &= ~INT_EVENT_DISCONNECT;

        //
        // Power the USB bus.
        //
        MAP_USBHostPwrEnable(USB0_BASE);
    }

if(g_sUSBHCD.ui32IntEvents & (INT_EVENT_DISCONNECT |
							  INT_EVENT_VBUS_ERR |
							  INT_EVENT_POWER_FAULT))
{
	//
	// Set the pipe state to error.
	//
	g_sUSBHCD.psUSBOUTPipes[ui32PipeIdx].iState = ePipeError;

	//
	// Needs to be set to exit out of large while loop.
	//
	ui32RemainingBytes = 0;

	g_sUSBHCD.ui32IntEvents &= ~INT_EVENT_DISCONNECT;

	break;
}

I reverted the changes and went to my original problem to gather more information. So when I am stuck in the PipeWrite. I notice that 

g_sUSBHCD.ui32IntEvents is equal to 0x14 which means INT_EVENT_SOF and INT_EVENT_DISCONNECT are set but I never exit the while(1) loop

I went into the disassembly window and here is what it is showing:

I am guessing #13 is INT_EVENT_DISCONNECT | INT_EVENT_VBUS_ERR | INT_EVENT_POWER_FAULT

The value for R1 is 0x10 shouldn't it be 0x14?

Thanks

Yes, that is correct.

 Amit,

I typecasted the structure as a volatile structure and that seemed to fix the issue. Thank you. Will a fix for this issue be included in the updated driver?

As I mentioned before there are 2 very similar boards that use the USB functionality one uses the TIVA M4 and the other uses stellaris M3. They both had the same issues with the board switching from host to device and being stuck in either a pipe read or a pipe write. I used a similar fix used in the M4 on the M3 driver and it seemed to work, However, after recovering from the disconnect on the M3 I plug the usb stick back in and when I try to do a write or read I get stuck in the following while loop:

        while(g_sUSBHCD.USBOUTPipes[ulPipeIdx].eState == PIPE_WRITING)
        {
            //
            // Read the status of the endpoint connected to this pipe.
            //
            ulEPStatus = MAP_USBEndpointStatus(USB0_BASE,
                                               INDEX_TO_USB_EP(ulPipeIdx + 1));

            //
            // Check if the device stalled the request.
            //
            if(ulEPStatus & USB_HOST_OUT_STALL)
            {
                //
                // If uDMA is being used, then disable the channel.
                //
                if(ulPipe & EP_PIPE_USE_UDMA)
                {
                    MAP_uDMAChannelDisable(UDMA_CHANNEL_USBEP1TX +
                                           (ulPipeIdx * 2));
                }
            }

            //
            // If a disconnect event occurs the exit out of the loop.
            //
            if(g_ulUSBHIntEvents & INT_EVENT_DISCONNECT)
            {
                //
                // Set the pipe state to error.
                //
                g_sUSBHCD.USBOUTPipes[ulPipeIdx].eState = PIPE_ERROR;
            }
        }

The g_ulUSBHIntEvents is set to INT_EVENT_SOF. I noticed that in the interrupt handler that I am not able to reach the statement 

           if(g_sUSBHCD.USBOUTPipes[ulIdx].eState == PIPE_WRITING)

becuase of

        if((g_ulDMAPending == 0) && (ulStatus == 0))
        {
            break;
        }

 Here is the change I made on the M3 to handle disconnect

        if(ulRemainingBytes < 64)
        {
            ulByteToSend = ulRemainingBytes;
        }
        if(g_sUSBHCD.USBOUTPipes[ulPipeIdx].eState == PIPE_ERROR)
        {
            //
            // An error occurred so stop this transaction and set the number
            // of bytes to zero.
            //
        	ulRemainingBytes = 0;
            ulSize = 0;
            break;
        }

Let me know if I need to clarify anything.

Thanks

Yes. I also had to remove the "else" from the "else if" statment in

if(g_sUSBHCD.USBOUTPipes[ulPipeIdx].eState == PIPE_ERROR)

It would never reach it becuase

if(ulRemainingBytes < 64)

was always true

Amit,

I cannot seem to find anything helpful. Should I start a new thread?

Thanks

Amit,

I tried something in the USB driver on the M3. I added

                MAP_uDMAChannelDisable(UDMA_CHANNEL_USBEP1TX +
                                       (ulPipeIdx * 2));

 Whenever it detected a disconnect in the pipewrite. I found that this is what happens when there is a pipe stalled event. It seemed to fix the issue. Does this make since?

I attempted this because I noticed after recovering from the disconnect on the M3 I would get stuck in pipwrite(most of the time) or piperead but this time it was waiting for a status change from the inthandler:

while(g_sUSBHCD.USBOUTPipes[ulPipeIdx].eState == PIPE_WRITING)

but there would be no dma transfer pending and the inthandler would not change the status of the pipe.

Let me know if this needs more clarification

Thank you for your help

Hello,

I've got another problem. I'm running usb_host_mouse example on EK-TM4C1294XL again. There is a HUB and a FS device connected to the HUB. The FS device can be pendrive, USB serial converter, etc. There is a test script, which connects/disconnets the device for 200 ms, then reconnects. After 2-4 cycles the SETUP packet is sent forever, because it is not ACKed. The interesting thing is that this error can be reproduced with our (HCC Embedded) USB host stack, which has a totally different implementation of TM4C1294's USB driver.

The test schematic is attached (note: the HUB can be HS or FS hub as well), the test script:

#!/bin/sh
for i in `seq 4`; do
  echo "Test #$i..."
  usb_switch_client off
  sleep 1
  usb_switch_client on
  sleep 0.2
  usb_switch_client off
  sleep 0.2
  usb_switch_client on
done

Hi Peter,

Suggestion 1:

Peter Ivanov said:

There is a test script, which connects/disconnets the device for 200 ms, then reconnects.

Suggestion 2:
If you would like to speed up the host stack response, assign shorter interval to the interrupt IN EP than its original bInterval at hub enumeration.

Although many hubs report full 255ms interval at the interrupt EP descriptor, PC OS used to poll it much quicker. For example, Windows polls it at 32ms, because 32ms is the max interval for the full-speed interrupt EP on Windows.
USB spec allows shorter interval [**1]

To assign shorter interval, modify the hub code on the host stack.

\TivaWare_C_Series-2.1.0.12573\usblib\host\usbhhub.c

static void *
HubDriverOpen(tUSBHostDevice *psDevice)
{

line 702:   USBHCDPipeConfig(g_sRootHub.ui32IntInPipe,
                             psEndpointDescriptor->wMaxPacketSize,
                             psEndpointDescriptor->bInterval,        // <--------
                             psEndpointDescriptor->bEndpointAddress &
                             USB_EP_DESC_NUM_M);

In above original code, USBHCDPipeConfig() takes the endpoint bInterval (psEndpointDescriptor->bInterval) directly.
Chenge this line, for example,

#define HUB_MAX_POLLING_RATE  32
(psEndpointDescriptor->bInterval < HUB_MAX_POLLING_RATE) ? psEndpointDescriptor->bInterval : HUB_MAX_POLLING_RATE,


[**1]
5.7.4 Interrupt Transfer Bus Access Constraints (usb_20.pdf)
An endpoint for an interrupt pipe specifies its desired bus access period. A full-speed endpoint can specify a desired period from 1 ms to 255 ms. ... The USB System Software will use this information during configuration to determine a period that can be sustained. The period provided by the system may be shorter than that desired by the device up to the shortest period defined by the USB (125 us microframe or 1 ms frame). The client software and device can depend only on the fact that the host will ensure that the time duration between two transaction attempts with the endpoint will be no longer than the desired period.

Tsuneo