I tried to replicate this issue here, but I was not successful in doing so.
I configured an interrupts endpoint with maxPacketSize=8, serviceInterval=1, and no bursts. Then defined a MANUAL_OUT DMA channel of size=16, count=1. Filled the 16-byte buffer with some data and committed 8 bytes. In the callback, I commit 8 bytes each time there is a consumer event. On the host side, I use ControlCenter and request for 8 bytes, and get exactly 8 bytes each time. The behaviour is the same on high speed and super speed connections.
Can you give details of how you were able to replicate it using a separate interrupt endpoint? And how do you detect that FX3 is sending 16 bytes instead of 8 bytes? Maybe if you can attach your firmware here, I can try to compare the endpoint/DMA configurations.
Thanks for your help! I think the below is the difference between our firmware:
> In the callback, I commit 8 bytes each time there is a consumer event.
I'm filing and committing 16 bytes at a time rather than filling with 16 bytes then committing 8 bytes at a time. The FX3 running at high/full speed automatically breaks the 16 byte commit into two 8 byte packets, but this doesn't happen at super speed. If you commit 16 bytes at a time, you should be able to replicate what I'm seeing. Maybe this is just an undocumented feature at high/full speed?
I'll try splitting the HID data into two 8 byte commits. This should be fine for my app.
> Can you give details of how you were able to replicate it using a separate interrupt endpoint?
I used code similar/copied from the bulksrcsink example firmware in the SDK, but obivously committing 16 bytes at a time.
> And how do you detect that FX3 is sending 16 bytes instead of 8 bytes?
Hardware analyzer between the FX3 and XHCI (both LeCroy T3 and Ellisys 280 show the same).
Thanks again for you help,
Just replying to confirm that committing 8 bytes at a time works, HID interface now works fine at super speed.