cancel
Showing results for 
Search instead for 
Did you mean: 

Real bug in the USB CDC

ksa
Associate
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
9 REPLIES 9
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
Associate
Posted on December 24, 2014 at 12:32

Hello 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
Associate II
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
ST Employee
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-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

mathieu
Associate
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
ST Employee
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-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

mathieu
Associate
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
Senior
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
Associate II
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.