Implementation of USB isochronous transfers in (at least some) STM32 microcontrollers has a very weird feature.
It's called EONUM (Even/Odd frame) field.
Basically, the value of the field determines on which frames – odd or oven – isochronous transfers will be received by the microcontroller. So, if you're sending your data every frame, unless you flip the value of the field every frame, you'll get exactly 50% packet "loss".
Flipping the field every frame looks really troublesome, and I can't really see how this feature is useful in any way. The manual barely mentions the feature (search for EONUM, SODDFRM or SEVNFRM), but provides no explanation whatsoever.
This looks somewhat similar to data toggle synchronization for e.g. bulk transfer (which is mandated by the standard), but from what I can tell, the USB spec says nothing about such or similar kind of synchronization for iso transfers (my STM32 processor supports full speed only, so PID sequencing has nothing to do with it, either).
The data transmitter and receiver must have their sequence bits synchronized at the start of a transaction. The synchronization mechanism used varies with the transaction type. Data toggle synchronization is not supported for isochronous transfers.
High-speed, high-bandwidth isochronous and interrupt endpoints support a similar but different data synchronization technique called data PID sequencing. That technique is used instead of data toggle synchronization. Section 5.9.1 defines data PID sequencing.
In the end, I simply set EONUM accordingly to current frame number in SOF handler to achieve loss-free transfer.
Can anyone explain the purpose of the feature?
You can find a few mentions of people battling with this feature over the internet, e.g. here: http://www.chibios.com/forum/viewtopic.php?f=16&t=926
Best Answer
The feature is there so that you don't have to worry that the buffer from which you're reading/writing the data is being overwritten with new data. You're expected to have two buffers and swap them over yourself, you're reading/writing one in software whilst the hardware is writing/reading the other one.