issue with small interrupt MPS at super speed

[Anonymous]

Hi,

   

I'm working on a composite device that includes a HID interface, which requires an 8 byte MPS (max packet size) interrupt IN endpoint to send data.  The problem is that, when the FX3 is running a super speed, it always sends out more data than the MPS.  Specifically, the DMA buffer minimum size is 16 bytes, so it sends 16 bytes, which causes a bus error (and the host controller resets the device).  The HID data payload is 16 bytes total, so one might think that just upping the MPS to 16 bytes would work, but the OS's generic HID driver is submitting two 8 byte URBs regardless of the MPS setting, which will then fail with a babble error.  This problem doesn't exist when the FX3 is running at high or full speed (using same DMA/buffer firmware code, the device sends in two 8 byte packets).  I also threw together a vendor specific (non-HID_ interrupt IN endpoint interface and replicated the problem at 8 bytes (16 bytes is OK since I have control and can submit a 16 byte URB).  In any case, AFAICT at this point, this is a bug in the FX3.  I haven't found any release notes listing this issue and I'm using the latest 1.2.3 SDK.

   

Is there any other way I can force an 8 byte packet at super speed or any other workaround for this problem?

   

Thanks,
Perry

[Anonymous]

 Hi Perry,

   

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.

       

Regards

   

Shashank

[Anonymous]

Hi Shashank,

   

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,

   

Perry

[Anonymous]

Just replying to confirm that committing 8 bytes at a time works, HID interface now works fine at super speed.