cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L476RG CubeMX generated USB CDC code stops transmitting out of the blue

Sven Köhler
Associate III
Posted on February 24, 2018 at 01:09

I soldered a USB cable to pins PA12 and PA11 on the Nucleo-L476RG board. In CubeMX I enabled USB with its default settings, disabled DMA (it's not supported for FullSpeed USB anyway) and generated the code. I used the latest CubeMX (4.24) as well as the latest CubeL4 (v1.11.0) available.

I adjusted main.c so that it sends data in a loop. This is the code inside the main method:

uint32_t x = 0;

static char buf[1024];

while (1) {

  size_t len = sprintf(buf,

    '0123456789' '0123456789' '0123456789' '0123456789' '0123456789'

   

'0123456789' '0123456789' '0123456789' '0123456789' '0123456789'

   

'0123456789' '0123456789' '0123456789' '0123456789' '0123456789'

   

'0123456789' '0123456789' ' %u\r\n', x++);

  uint8_t ret = CDC_Transmit_FS(buf, len);

  HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin,

    ret == USBD_OK ? GPIO_PIN_SET : GPIO_PIN_RESET);

}

The CDC_Transmit_FS function is as generated by CubeMX. It checks the TxState and returns USBD_BUSY if the USB is busy sending. If the USB is not busy, it calls USBD_CDC_SetTxBuffer and transmits the packet via USBD_CDC_TransmitPacket.

The CDC_Receive_FS function is also as generated by CubeMX. It simply calls USBD_CDC_SetRxBuffer and USBD_CDC_ReceivePacket. The data written into the buffer is never actually used.

On the PC (Linux in this case), I start a terminal program (picocom) to display all the text that arrives on the virtual COM port /dev/ttyACM1. The lines are displayed in my terminal window just fine - but then stop inexplicably. When it stops, the output usually looks something like this:

01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 121520

01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 121521

01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 121522

4567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 121523

01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 121525

As you can see, line 121523 is shorter than the others and doesn't start with a zero. The last line is complete, but after that line, the transmission has stopped. Sometimes it takes a while to fail. Sometimes it stops working after just a few lines.

I know that CDC_Transmit_FS doesn't wait until the transmission has finished. However, as long as transmission is in progress, it should return USBD_BUSY and it should not disturb any ongoing transmission.

Does somebody have a similar experience? Did somebody get USB to work reliably?

I could very that TxState stays 1 and is not reset to zero.

I have read horrible things here about ST's USB CDC code (race conditions have been found in the past) and it looks like the L4 code still contains such a race condition. 

#usb-fs-cdc #stm32l4-usb
9 REPLIES 9
Szymon PANECKI
Senior III
Posted on February 25, 2018 at 13:49

Hello Sven,

During STM32L4trainings I use attached presentation to show step by step how to develop simple USB CDC application. Hardware used for this excercise is STM32L4 Discovery kit, but if you select in STM32CubeMX device from Nucleo (L476RG) instead of device fromDiscovery (L476VG), you will be able to use exactly the same approach to the one presented in my slides.

Could you please review these slides and try to develop this application? I hope it will work in reliable way on your side.

Regards

Szymon

________________

Attachments :

STM32L4 USB VCP.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxsN&d=%2Fa%2F0X0000000b2Y%2FTPX_NFqVFfweAISP1YO3PDDPHXqpPClIHVYTgaJcmEY&asPdf=false
Posted on February 25, 2018 at 13:53

Szymon,

How to access the presentation you are talking about?

I use the USB CDC a lot and sometimes I observer the same symptoms as described in this post.

So would like to see ST recommended approach.

Thanks,

Bogdan

Posted on February 25, 2018 at 13:57

Hello,

You should be able to see it below my message. I can see it on my side like on picture below. Is it visible also for you?

0690X00000609nuQAA.png

Regards

Szymon

Posted on February 25, 2018 at 14:02

Unfortunately not. It is not the first time when you share valuable pdf files but I cannot see them. Initially I was thinking that you send these file using private message.

MAybe I canno use this forum,

What I see:

0690X00000609cFQAQ.png
Posted on February 25, 2018 at 14:12

Thanks for the feedback. I am sorry for this inconvenience. I was not aware of this problem. Unfortunately I am not able to tell you how to solve it. 

Let me share the file by google drive. Please you

https://drive.google.com/open?id=10i_xkGMVxxRLeCv9gPrEVU1fD_5Y4PQY

. This should work.

Regards

Szymon

Posted on February 25, 2018 at 14:15

No problem. Thanks for sharing this. I have similar training material for F4 but this one seems to be fresher.

Posted on February 25, 2018 at 15:23

First of all, I can download your slides just fine.

My code is almost identical to yours - except the Delay of 500ms which I don't want since my application is supposed to send data out as fast as possible.

The source of my USB clock was not set to MSI. It was set to PLLSAI1Q and the MSI clock was set to 4kHz. Might that have been the source of my problems?

USB is running stable now, it seems, but the CPU is clocked at 48MHz now instead of the 32MHz that it used to run at. I still have to see whether I can go down with the CPU clock without problems.

Update:  The CPU clock is now 20MHz derived from HSI via PLL while the USB clock source is MSI set to 48MHz. So far, it just works rock solid. It's sending for 20 Minutes now without stopping unexpectedly. 

Posted on February 26, 2018 at 21:06

It might be surprising but today I can see your original attachment. So maybe I was too impatient;).

I seems that the forum is working fine  - no need to worry.

0690X00000609Y2QAI.png
mike
Associate

can you share the pdf?