USB Interrupt Taking a Long Time

Timothy Eastham

Other Parts Discussed in Thread: AM1808

I am using StarterWare_1_00_03_03 with an AM1808. I am using the usb_dev_bulk example to echo data. I modified the usbhandler.c file to add a bit toggle when I enter the USB0DeviceIntHandler() function. Below is the code if you want to see it. I am watching the toggle on a scope and sometimes the handler is taking 100s of milliseconds to complete. Does anyone know why it would take that long to complete the handler? If I understand the architecture correctly, this handler is called from the USB ISR.

void
USB0DeviceIntHandler(void)
{
unsigned int ulStatus = 0;
unsigned int epStatus = 0;
paddr = (int*)(0x660000F4);
*paddr |= 0x04;
#if defined(am335x) || defined(c6a811x) || defined(am386x) || \
defined(c6741x)
//
// Get the controller interrupt status.
//
ulStatus = HWREG(USB_0_OTGBASE + USB_0_IRQ_STATUS_1);
//
// Get the EP interrupt status.
//
epStatus = HWREG(USB_0_OTGBASE + USB_0_IRQ_STATUS_0);
//
// Clear the controller interrupt status.
//
HWREG(USB_0_OTGBASE + USB_0_IRQ_STATUS_1) = ulStatus;
//
// Clear the EP interrupt status.
//
HWREG(USB_0_OTGBASE + USB_0_IRQ_STATUS_0) = epStatus;

#ifdef DMA_MODE
HWREG(USBSS_BASE + USBSS_IRQ_STATUS) =
HWREG(USBSS_BASE + USBSS_IRQ_STATUS);
#endif
//
//Call the Interrupt Handler.
//
USBDeviceIntHandlerInternal(0, ulStatus, &epStatus);
//
//End of Interrupts.
//
HWREG(USB_0_OTGBASE + USB_0_IRQ_EOI) = 0;

#ifdef DMA_MODE
HWREG(USBSS_BASE + USBSS_IRQ_EOI) = 0;
#endif

#else
//
// Get the controller interrupt status.
//
ulStatus = HWREG(USB_0_OTGBASE + USB_0_INTR_SRC);
epStatus = 0;
// Clear the Interrupts
HWREG(USB_0_OTGBASE + USB_0_INTR_SRC_CLEAR) = ulStatus;
#ifdef _TMS320C6X
IntEventClear(SYS_INT_USB0);
#else
IntSystemStatusClear(SYS_INT_USB0);
#endif

//
// Call the internal handler.
//
USBDeviceIntHandlerInternal(0, ulStatus, NULL);

// End of Interrupts
HWREG(USB_0_OTGBASE + USB_0_END_OF_INTR) = 0;
#endif
*paddr &= ~0x04;

}

over 12 years ago

0 Vineeth Balan over 12 years ago

TI__Intellectual 1640 points

Hi Timothy,

You have not mentioned the device example on which you have made your changes. It would be helpful if you could explain your use case in a more detailed manner.

With reference to your query ( http://e2e.ti.com/support/embedded/starterware/f/790/p/247878/899398.aspx#899398) I conclude that your's is an isoch device .

As you can see from the handler code, the only piece of code which can eat up time is the function call USBDeviceIntHandlerInternal () which does the job of parsing though the device registers to find the actual cause of interrupt. The handler then proceeds to handle endpoint events such as RX and TX or enumeration. My guess is that there is an RX or TX happening during this time which actually causes the execution time to bloat. Have you added any iscoh handling code to USBDeviceIntHandlerInternal () or to any other function in the call stack? Would it be possible for you to give a brief on how the Isoch device was implemented.

0 Timothy Eastham over 12 years ago in reply to Vineeth Balan

Intellectual 360 points

My project is based upon the uartecho example. I have added in the usb stuff based upon the bulk usb example. I have also added in the GPIO stuff from the GPIO example. I am sending commands through USB and hardware is toggling a GPIO, which has an interrupt assigned to it. As noted in the other query, the GPIO has a higher priority but that doesn't really matter because nesting does not exist. I can watch on the logic analyzer as my GPIO never takes more than microseconds to service but the USB takes 100s of milliseconds. Once the USB starts a transfer, does the interrupt hang out until all the bytes are transmitted? Is that the reason for the 100s of ms of time to service it?

I am just trying to make sure that this long time period is normal or if I have a condition that needs attention.

Thanks,

Tim

Processors

Processors forum

USB Interrupt Taking a Long Time