Other Parts Discussed in Thread: EK-TM4C1294XL, TMS320VC5506
I'm working on the EK-TM4C1294XL connected LaunchPad with the USB library in Host only mode (eUSBModeForceHost). I have two identical endpoints, #1 and #2, but I'm seeing data corruption on EP#1 every 45 to 49 ms, and always around the 256th byte of a 386 byte packet. I'm using SW-TM4C-2.1.0.12573 because that's what I started with years ago.
The other end of my USB connection is a TMS320VC5506 that has a custom class with a non-default configuration containing two endpoints, #1 and #2. Both are IN endpoints marked with a length of 388 bytes, and which always transfer 386 bytes exactly (or 0 bytes in the rare case that the 976.5625 Hz data update rate falls short of the 1000 Hz USB frame rate). The TMS320 firmware is proven, and I've also hooked up a Total Phase Beagle USB 480 Power analyzer to confirm that the data is not corrupt on the wire. The isochronous packets have 384 bytes of data followed by a 16-bit sequence number, which allows me to match packets seen on the Beagle USB analyzer with packets seen on the ARM chip. The Device is Full Speed, and the custom class protocol uses at least 75% of the available bandwidth.
My TM4C1294 code starts by scheduling both endpoints, and then scheduling continued streaming within the callback as each packet arrives. This seems to work perfectly for endpoint 2, but perhaps there is a timing issue. Looking at my sequence numbers, the bad packets are 45 sequence numbers apart, sometimes 49. I have a pair of circular buffers for the two endpoint streams, and those are 4 packets deep, so the same memory is being reused every 4th packet. If there were any memory corruption errors in my firmware, it would seem that they should occur more often than once every 45 or so buffer pairs (meaning 45 packets each from the 2 endpoints).
How well proven is the TM4C USB peripheral in isochronous streaming mode? How many people are using multiple endpoints? How many people have packet sizes greater than 256 bytes? I'm not sure where to look, but it seems like any of these details could be unique to my situation. I'm sure that folks have been streaming audio with this chip, but what about a couple of large, isochronous endpoints that consume nearly all of the full speed bandwidth?
I've looked through the errata, and see no USB problems that would affect this. Are there bug fixes in the USB library that are documented?
Is it possible that the USB library or USB peripheral are not properly reporting the 0-byte packets? I always skip advancing the circular queue pointer when the size returned in the callback is 0. If my math is right, the 976.5625 Hz update rate should result in an empty packet once every 41 or 42 frames, which seems suspiciously close to the error rate at 45 to 49 sequence numbers apart.
Brian Willoughby
Madrona Labs