HAL_PCDEx_SetTxFiFo and fifo number/order

[Jerome Godbout]

Hi, I'm having a hard time understanding the HAL_PCDEx_SetTxFiFo() function that I should call inside the USBD_LL_Init() function for my Stm32L476. I have attach my descriptor results from USBTreeView. But here the highlight:

My composite device have multiple interface:

• 1 HID interface
  • 1 interrupt IN EP 0x83
• 1 interface for application
  • 1 Bulk IN EP 0x84
  • 1 Bulk OUT EP 0x04
  • 1 interrupt IN EP 0x85
  • 1 ISO IN EP 0x86
• IAD Link both CDC interfaces
  • 1 CDC Control interface
    • 1 Interrupt IN EP 0x82
  • 1 CDC Data interface
    • 1 Bulk IN EP 0x81
    • 1 Bulk OUT EP 0x01

I did keep the IAD and CDC as the last into the descriptor since it seem to confuse some COM driver. But I still have a hard time with my endpoints and the call to init the TX buffer, I'm not sure I do the right thing.

Does HAL_PCDEx_SetTxFiFo() use for the fifo 2nd argument :

1. the endpoint id without the direction (& ~0x80)?
2. the order they appear into descriptor and interface number?

What is it represent exactly? Can I skip some? How much can be used, is 6 too much?

It seem like if I remove my application endpoints my CDC work normally and when I add them my write cannot be perform since the

CDC_Transmit_FS()

if (hcdc->TxState != 0){

  return USBD_BUSY;

 }

The TXState is always busy. This even if no driver and I do nothing with the other endpoints, the CDC stop working. I suspeect I don't do the rith thing with my tx buffer init with HAL_PCDEx_SetTxFiFo 

HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 0, 0x40); /* Default control EP */

   HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 1, 0x40); /* CDC bulk EP */

   HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 2, 0x10); /* CDC interrupt EP */

   HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 3, 0x10); /* HID interrupt EP */

   HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 4, 0x40); /* App bulk EP */

   HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 5, 0x40); /* App interrupt EP */

   HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 6, 0x40); /* App isochronous EP */

Maybe I got this wrong, I'm just not sure how this get link to the proper endpoint or if I overflow the RX space (I have read the F4 only support 0..5, not sure if this is true for the L4?).

Does the descriptor order and interface order and endpoint numbering have any requirements? like does the lowest interfaces should have the lowest endpoints numbers?

[Jerome Godbout]

Yeah right, forgot to include the RX into my calculation. My bad sorry. is the RX need to be twice as much as the maximum packet on a single endpoint?

I can easily reduce the App bulk to 0x20 saving 0x20, but I still need to find another 0x10, not sure I can go below 0x10 (I think they must be by 16 bytes chunk is that correct?). Maybe the CDC can work with 0x30 or default control 0x30. I will have to test this out.

[waclawek.jan]

Rx FIFO size has been discussed above. Theoretically, it should accomodate once the largest packet, plus enough space for SETUP packet(s) plus the control markers the core pushes into FIFO at various moments.

The RM explicitly mentions that minimum value for the FIFO sizes is 16, which would be 64 bytes per FIFO. I'm not sure that's a real requirement of the OTG module, but I am not an authoritative source of information.

JW

[Jerome Godbout]

Thanks again for the help, I did fix this, and found the pClassData was overwritten by all composite class (old code and cubeMX mix together that was not checked properly). After fixing the buffer size and make sure pClassData structure are split for each class it seem to work fine. The serial com port is working just fine, my custom bulk and interrupt seem to work for a while before hanging, but that probably an issue with my application buffer and state management, it does stop on the 10th transfer.

Thanks again that was helpful. I still wonder how this thing was working in the first place, corrupted pClass structure (C and void* struct ain't fun to debug).

In the end I did decrease the rx buffer to 0x70, since the control 0x30 or CDC 0x30 was not really stable on all OS. I hope it will be enough, else I will have to reduce the app bulk down to 0x10, which is not much but could be good enough to have multiple packet for a given payload.