[stm32u585 USB] Modifying RxFIFO size twice before HAL_PCD_Start breaks EP0_IN transmission

[lll]

Hello,

I have encountered a critical issue regarding the USB OTG peripheral FIFO allocation during the static initialization phase (before calling HAL_PCD_Start() ).

The Issue:

If I resize the Rx/Tx FIFOs twice with the sequence of "Large Size first, then Small Size", the Endpoint 0 (EP0 IN) completely fails to transmit any data (it freezes/stalls) after the hardware starts.

• Scenario A (Works perfectly):
  Set Rx FIFO to 0x100 (Words) ➡️ Set Tx FIFO 0 to 0x16. (Single configuration works).
• Scenario B (Fails completely):
  First call: Set Rx FIFO to 0x100, Tx FIFO 0 to 0x16.
  Second call (immediately after): Set Rx FIFO to 0x25, Tx FIFO 0 to 0x16.
  Result: EP0 IN never transmits any packet afterward.

My ultimate goal is to dynamically reconfigure and shrink the FIFO layout at runtime when receiving the SET_CONFIGURATION request from the host, allowing the device to adapt to different configurations

[Jason Miller234]

 

This looks more like a USB OTG core/FIFO reconfiguration limitation than an EP0 issue. I'd verify that the FIFO RAM layout is recalculated correctly after the second resize, flush both Rx/Tx FIFOs before restarting the core, and ensure the USB core is idle before changing FIFO registers. Also, which STM32 family are you using (F4/F7/H7/U5)? That detail and your FIFO setup code would help identify whether it's a HAL bug or expected hardware behavior.

[lll]

i’m using stm32u585, i add flush and reopen. still have issues

    HAL_PCDEx_SetRxFiFo(&hpcd_USB_OTG_FS, 0x100);
    HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 0, 0x10);

    HAL_PCD_EP_Flush(&hpcd_USB_OTG_FS, 0x00);
    HAL_PCD_EP_Flush(&hpcd_USB_OTG_FS, 0x80);

    HAL_PCD_EP_Close(&hpcd_USB_OTG_FS, 0);
    HAL_PCD_EP_Close(&hpcd_USB_OTG_FS, 0x80);
    HAL_PCD_EP_Flush(&hpcd_USB_OTG_FS, 0x00);
    HAL_PCD_EP_Flush(&hpcd_USB_OTG_FS, 0x80);
    HAL_PCDEx_SetRxFiFo(&hpcd_USB_OTG_FS, 37);
    HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 0, 0x10);
    HAL_PCD_EP_Open(&hpcd_USB_OTG_FS, 0, 64, 0);
    HAL_PCD_EP_Open(&hpcd_USB_OTG_FS, 0x80, 64, 0);
    HAL_PCD_EP_Abort(&hpcd_USB_OTG_FS, 0x80);
    HAL_PCD_EP_Flush(&hpcd_USB_OTG_FS, 0x80);

    HAL_PCD_Start(&hpcd_USB_OTG_FS);
    lusbd_hal_ep_open(dev_idx, 0, 0, 64, 0);
    lusbd_hal_ep_open(dev_idx, 1, 0, 64, 0);

 

[lll]

It seems to be an issue with the fifo size. When the size is set to 38, it doesn't work, but it works fine when set to 39

Device RxFIFO = (5 * number of control endpoints + 8) + ((largest USB packet used / 4) + 1 for status information) + (2 * number of OUT endpoints) + 1 for Global NAK

The formula in rm0456 seems incorrect. What is the correct calculation method

[FBL]

Hi ​@lll ​@Jason Miller234 

About FIFO memory organization, 

• IN endpoints: Each active IN endpoint has its own dedicated Tx FIFO buffer.
• OUT endpoints: All OUT endpoints share a single Rx FIFO buffer. → so in my understanding, you cannot resize it afterword, but I need to recheck and get back to you. 

You can refer to this article as well How to configure USB FIFO over USB OTG controller on STM32 in device mode | Community

[lll]

hello,

Adding 8 to the calculation result of the formula(Device RxFIFO) can work normally, is this(+8) right? What is the correct calculation method

[FBL]

Hi @lll,

if you are asking why 37? FIFO size should be interpreted as a word count and the value is typically written in hexadecimal when programming the register.

In general, the Rx FIFO is not used only for OUT data payloads. It must also reserve space for internal USB core traffic, including:

• SETUP packets for the control endpoint: 13 words (52 bytes)
• Largest received packet
• One additional word for status information
• Two words per OUT endpoint
• One word for the global OUT NAK

So the Rx FIFO size can be calculated : 13 + ((largest USB packet size) / 4 + 1) + (2 × number of OUT EP) + 1 ​

I’m not sure if the value 256 words is exactly on the edge in your case since you didn’t provide further details about your application. However, if your configuration works correctly with a larger Rx FIFO, you can keep that margin.