cancel
Showing results for 
Search instead for 
Did you mean: 

Bug: CDC does not transmit packets which length is an exact multiple of 64 bytes

JThev
Associate II

The problem was seen with STM32F303RD and STM32Cube_FW_F3_V1.10.0, but there is a possibility that other parts might be affected.

When using USBD_CDC_SetTxBuffer followed by USBD_CDC_TransmitPacket with a packet of 64, 128, 192, etc. bytes, the data are not sent unless they are followed by another call to those functions with data length different than multiple of 64 bytes.

A fix in the HAL library in explained in the thread below:

https://community.st.com/s/question/0D50X00009XkXmgSAF/usb-cdc-breaks-on-heavy-load

The fix is in PCD_EP_ISR_Handler function of the stm32f3xx_hal_pcd.c file. In one of the last lines of the function:

if (ep->xfer_len == 0U)

To be replaced by:

if ((ep->xfer_len == 0U) && (ep->xfer_count < ep->maxpacket))

The last lines of the function code would look like:

        /*multi-packet on the NON control IN endpoint*/
        ep->xfer_count = PCD_GET_EP_TX_CNT(hpcd->Instance, ep->num);
        ep->xfer_buff+=ep->xfer_count;
       
        /* Zero Length Packet? */
        if ((ep->xfer_len == 0U) && (ep->xfer_count < ep->maxpacket))
        {
          /* TX COMPLETE */
          HAL_PCD_DataInStageCallback(hpcd, ep->num);
        }
        else
        {
          HAL_PCD_EP_Transmit(hpcd, ep->num, ep->xfer_buff, ep->xfer_len);
        }

1 ACCEPTED SOLUTION

Accepted Solutions
JThev
Associate II

The pull-up request doesn't seem to work for now. I openned an issue instead: https://github.com/STMicroelectronics/STM32CubeF3/issues/2

View solution in original post

3 REPLIES 3

Great catch. Can you try making a pull request and let us know if STM respond appropriately?

Thanks!

https://github.com/STMicroelectronics/STM32CubeF3

JThev
Associate II

The pull-up request doesn't seem to work for now. I openned an issue instead: https://github.com/STMicroelectronics/STM32CubeF3/issues/2

JThev
Associate II

The issue has been addressed by STM on Github. According to them, it should be fixed on the next release, planned for the end of 2019.