STM32 USB HAL TxFIFO Error

[MDS]

Posted on February 23, 2018 at 18:29

This is a reposting of

https://community.st.com/thread/45731-stm32f7-hal-ll-driver-bug?sr=inbox

 with a more descriptive name.

I am using the USB FS device with the CDC class. I used STM32CubeMX V4.23.0 with the STM32CubeF7 V1.8.0 add-on. The max packet size is set to 64 bytes and the EP TX FIFO buffer for the EP is set to 64 bytes in USBD_LL_Init(). I was sending various sized messages over the IN pipe. When I tried to send a 64-byte message, it failed...no transmit complete callback. Stepping through stm32f7xx_hal_pcd.c, I discovered in PCD_WriteEmptyTxFifo() &sharp1287 (see code below) the packet was not being written to the Tx FIFO for transmission. Here is the code in question:

while

( (USBx_INEP(epnum)->

DTXFSTS

& USB_OTG_DTXFSTS_INEPTFSAV) > len32b &&

// Fixed when changed > to >=

            ep->

xfer_count

< ep->

xfer_len

&&

            ep->

xfer_len

!= 0)

What is happening is that when a packet is rounded to long words and 'len32b' 

equals the Tx FIFO buffer size, the first condition of the above while() fails and the packet is not written to the FIFO. A re-enumeration is required to restore the EP to working.

When the '>' is changed to '>=', it works. I suspect that because packet sizes 61-64 bytes will round to 16 long words, all packets of these sizes will also fail. I verified that 63 byte packet fail. Probably increasing the Tx FIFO size to 128 bytes would also solve the issue, but I am using almost all of the EPs and I have run out of Tx FIFO buffer total size (1280 bytes).

Please correct this error and check for other boundary conditions in the next HAL release.

I also see the problem with the STM32H7 driver. I am using STM32CubeMX V4.24.0 and STM32H7xx V1.1.0. The line of code is here:

stm32f7xx_hal_pcd.c, PCD_WriteEmptyTxFifo(), &sharp1310.

#stm32-usb

[Khouloud GARSI]

Posted on February 27, 2018 at 11:23

Hi

Skelton.Merle

‌,

This is reported internally for further check. I will get back to you with any update on this point ASAP.

Sorry for any inconvenience this may have caused.

Khouloud.

[waclawek.jan]

Posted on February 27, 2018 at 19:09

Probably increasing the Tx FIFO size to 128 bytes would also solve the issue

Well, as you've demonstrated, the real solution is to change > to >=.

Increasing TxFIFO size by one word would 'solve' the issue, too. 'Cover up' would probably describe this better, and this is also the reason why it escaped so far.

Another solution is to rewrite that function to calculate length data-to-be-sent by taking into account the remaining space in FIFO - data would be fragmented but it would become more robust.

I believe this affects Cuben of all models having the Synopsys OTG-USB module, IIRC they are in 'F1, 'F2, 'F4, 'L4, 'F7. I've looked briefly at the older SPL-based STM32_USB-Host-Device_Lib_V2.1.0 and it appears to be affected in the very same way, too - in usb_dcd_int.c, DCD_WriteEmptyTxFifo():

[...]

  len32b = (len + 3) / 4;

  txstatus.d32 = USB_OTG_READ_REG32( &pdev->regs.INEP_REGS[epnum]->DTXFSTS);        while  (txstatus.b.txfspcavail > len32b &&          ep->xfer_count < ep->xfer_len &&            ep->xfer_len != 0)  {    /* Write the FIFO */

[...]

JW

[paolo239955_stm1_stmicro_com]

Posted on April 12, 2018 at 14:29

Thank a lot !!!

[Alex Beck]

Posted on May 05, 2018 at 13:23

I also just fixed this issue and then discovered this thread. Agree it now works.

[MDS]

Please note:

​I just update to STM32CubeMX V4.26.1 and the new CubeH7 processor library. This USB issue still exists in the new STM32CubeMX V4.26.1. If you update make sure to patch the USB driver to fix the error...again.

[Pavel A.]

We definitely need a bug tracker.

-- pa

[MDS]

I am not sure when this was fixed, but I just installed STM32CubeMX V5.2.0 and CubeH7 V1.4.0 and the error has been fixed. This thread can be considered completed.