Too Many USB Interrupts?

Kernel
1

Hi all. For some reason, we appear to be getting WAY too many USB interrupts, maybe you can shed some light on it?

Current setup:
NXP LPC4330
FreeRTOS 10.4.3
Using the USB ROM API that is on the LPC4330

Task List:
LED Task - Low priority, blinks LED
USB Task - Hi priority, processes packets that come in over the USB
USB Copy Task - Hi priority (same as USB Task), performs read from USB device, puts data into our own circular queue implementation, requeues a buffer to the device, and notifies USB Task that data is available

USB INT is highest priority. USB IRQ Handler calls into said ROM API (USBD_API->hw->ISR(…)) which eventually calls the bulk OUT, bulk IN, etc handlers.

The bulk OUT handler notifies and yields to the USB Copy Task via the FROM ISR functions.

I put some counters in to track how many IRQ handler calls were taking place compared to how many bulk OUT handler calls were taking place.

It would appear that there is a 40x difference. E.g. if my PC side test app sends 282049 packets, I am getting 282049 bulk OUT handler calls, but the IRQ handler is called 11838421 times. That seems excessive.

With our bare metal application, we don’t see the same behavior. We were expecting a couple IRQ handler calls per bulk OUT handler call.

Can anyone shed some light?

Thanks,

C-Coder

2

Are there any differences in the interrupt service routines between your bare metal and FreeRTOS examples? Specifically thinking about where the interrupt is cleared.

3

Fortunately/unfortunately, because we’re using the ROM code, we don’t deal with any of that. All we do is provide the ROM code with function pointers for different handlers and it takes care of the underlying INT line clearing etc.

4

It looks like NAKs are our problem. Now to speed up processing of buffers so that we don’t get all those NAKs. I’ll report back if this becomes the solution.