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?
