Skip to main content
JThev
Associate II
August 12, 2019
Solved

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

  • August 12, 2019
  • 3 replies
  • 1588 views

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);
 }

This topic has been closed for replies.
Best answer by JThev

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

3 replies

Dave Nadler
Senior III
August 13, 2019

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

Thanks!

https://github.com/STMicroelectronics/STM32CubeF3

JThev
JThevAuthorBest answer
Associate II
August 14, 2019

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

JThev
JThevAuthor
Associate II
August 20, 2019

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.