Dropped interrupt???

[johnstrohm]

We're using the MK51DN512CLQ10 processor with the USB 5.0 Beta stack, running as a USB device.  We have bidirectional isochronous traffic running, IN on one endpoint, OUT on a different one.  We have bidirectional HID traffic running.

We are using CodeWarrior.  Our code is in C++.  We are not using Processor Expert.

I use the class-specific callback for each direction of the isochronous traffic to schedule the next send/receive operation.  This has the drawback that, if I ever do not get the Token Done interrupt for an operation, I never schedule the next one.

That appears to be exactly what is happening.  I see the code run perfectly, for an amount of time that varies between a few minutes and 37 hours, and then the processor apparently drops a Token Done interrupt.  With no interrupt, I get no callback, and no more isochronous traffic on the endpoint that dropped the interrupt.

Sometimes I see it on the receive endpoint, sometimes on the transmit.  On the run that went 37 hours, it dropped the other direction about 7 minutes later.  Some time after that, it lost endpoint 0 traffic.  I do not know whether it continued to see Start-of-Frame interrupts on that run.  On the shorter runs, SOF continued after the first isochronous direction failed.

Data size is such that it should be sending everything in one USB data packet.  Ellisys USB analyzer captures seem to show that it is.  This says that the Token Done interrupt is the completion interrupt.

I've traced through the USB stack code.  If the code gets the Token Done interrupt for the endpoint at all, and it is for completion (as opposed to the m'th of n packets), it *WILL* call the class-specific callback.

Has anyone seen anything like this?  Any suggestions on what to look at?

[Jorge_Gonzalez]

Hello John Strohm:

The USB Stack 5.0 Beta was a transitional stack. The latest and improved version is included with KSDK v1.2:

Software Development Kit for Kinetis MCUs|Freescale

I recommend you to try that one.

Regards!

Jorge Gonzalez

[johnstrohm]

In Freescale document K51P121M100SF2V2RM.pdf, entitled "K51 Sub-Family Reference Manual", Table 44-5 on page 1071, entltled "USB responses to DMA overrun errors (continued)" says "In device mode, the BDT is not written back nor is the TOKDNE interrupt triggered because it is assumed that a second attempt is queued and will succeed in the future."

This appears to match the symptoms I see, which is that the hardware itself is dropping the interrupt, not the USB 5.0 stack.

Is there any known way to prevent the DMA overrun errors?