Real bug in the USB CDC

[ksa]

Posted on September 15, 2014 at 14:39

USBD_CDC_TransmitPacket() function contains a bug:

it sets the 'transmission in progress' flag AFTER starting the actual transmission, so if the 'transmission done' interrupt happens too early, the flag will be set AFTER the interrupt and hence will never be cleared. To fix this, move ''hcdc->TxState = 1'' line before the call to USBD_LL_Transmit() :

uint8_t  USBD_CDC_TransmitPacket(USBD_HandleTypeDef *pdev)

{         USBD_CDC_HandleTypeDef   *hcdc = pdev->pClassData;     if(pdev->pClassData != NULL)   {     if(hcdc->TxState == 0)     {

      /* Tx Transfer in progress */

      hcdc->TxState = 1;

      /* Transmit next packet */

      USBD_LL_Transmit(pdev,                        CDC_IN_EP,                        hcdc->TxBuffer,                        hcdc->TxLength);       return USBD_OK;     }     else     {       return USBD_BUSY;     }   }   else   {     return USBD_FAIL;   } }

This bug

we found

in practice, and

it was described

http://visualgdb.com/tutorials/arm/stm32/usb/

#cdc #stm32 #usb #usb #usb #library #bug #cdc #stm32cube

[Montassar BEN ROMDHANE_O]

Posted on September 16, 2014 at 16:27

Hi kukhtin.sergey,

Thank you for bringing this issue to our attention. We'll pass it along to our development team. Keep an eye our for the next update!Regards.

[jasonwatton]

Posted on December 24, 2014 at 12:32Hello Heisenberg,We are trialing ST and we have just fallen foul of this bug. Is this going to be fixed in the next STM32Cube release? When?Thanks,Jason.

[christoph2399]

Posted on October 05, 2015 at 13:55

bug is still not fixed!

cost me half a day to debug and find the problem. the call-stack finally showed that the interrupt clears the TxState before it's set. ________________ Attachments : callstack-cdc-bug.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzNo&d=%2Fa%2F0X0000000bMZ%2FHLFltVnA6UMa4aXykip2lrJ_wGx8CHb2mgRUi61MzBA&asPdf=false

[Amel NASRI]

Posted on February 05, 2016 at 12:30

Hi,

I confirm that the bug was fixed since the version 1.2.0 of STM32CubeL1 package (current one is 1.4.0).-Mayla-

[mathieu]

Posted on April 04, 2016 at 08:46

Hi Mayla, 

I am currently using a STM32F072  with STM32CubeF0 1.4 and I am still having this problem.Mathieu

[Amel NASRI]

Posted on April 04, 2016 at 11:47

Hi Mathieu,

The reported bug is already fixed since a while.This is the current implementation of USBD_CDC_TransmitPacket:uint8_t  USBD_CDC_TransmitPacket(USBD_HandleTypeDef *pdev){        USBD_CDC_HandleTypeDef   *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;    if(pdev->pClassData != NULL)  {    if(hcdc->TxState == 0)    {      /* Tx Transfer in progress */      hcdc->TxState = 1;            /* Transmit next packet */      USBD_LL_Transmit(pdev,                       CDC_IN_EP,                       hcdc->TxBuffer,                       hcdc->TxLength);            return USBD_OK;    }    else    {      return USBD_BUSY;    }  }  else  {    return USBD_FAIL;  }}It may be a different issue that you are facing. It should be better to clearly describe it.-Mayla-

[mathieu]

Posted on April 04, 2016 at 18:45

Hi Mayla 

first thank you for your quick answer. I do have this implementation of USBD_CDC_TransmitPacket in usb_dc.c. Yet, I still encounter this issue of TxState remaining equals to one, resulting in the microcontroller no longer writing. I use the USB communication in both directions, and this usually happens with dense traffic. I assume the situation where both the computer and the microcontroller can write at the same moment can happen. Would you have any recommandations regarding particular handshaking I would have to implement or things to avoid?Mathieu

[tsuneo]

Posted on April 05, 2016 at 19:20 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6q3&d=%2Fa%2F0X0000000bwX%2FLeVcvFuBi0SxJlIZ6mz6MbIKGb2k6wxNSITZe.9NfVE&asPdf=false

[greg239955_stm1]

Posted on April 11, 2016 at 06:37

I'm working on an RNDIS device on STM32F429, using Cube HAL V1.9.

I'm using the same method as CDC to detect when the output frame has gone, and frequently getting the same problem as described here for CDC, with the flag being stuck on.I've done all of the patches described here, but hasn't helped at all. Anyone got any other suggestions on how to fix this issue?Not sure if I'm still facing ST's issue or if its something in my class driver code.