STM32L0 USB CDC VCP Transmit problems

nlbutts · ‎2014-12-28

Posted on December 28, 2014 at 17:59

I am using an STM32L053 part and trying to use the USB CDC VCP functionality on an STM32L0-Discovery board. In the past I've gotten the USB CDC VCP functionality working on an STM32F4 on a custom board using the ST USB Library.

For the STM32L0 project I am using the STCubeMX. The first problem I encountered was the CDC receive would not work until I called

USBD_LL_PrepareReceive.

That was well documented in this link:

/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/USB%20middleware%20issue%20with%20CDCVCP%20only%20x%20packets%20receivable%20%28HAL%201.1.0%20and%20Host-Device_Lib%202.1.0%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=517

Now I am having problems with the CDC transmit. If I transmit 8 bytes or less the data is transmitted correctly. For example, I've been transmitting 12345678 and that comes out correctly. Keep in mind these are ASCII strings. Now if I try and transmit 123456789 I get 9 bytes of garbage. I've traced the code all the way down to PCD_WritePMA function. At that point it is still pointing to my buffer of data and the length is 9 bytes. I see it correctly grab the data and join it into 16-bits of data and then write it to memory location 0x40006000 which is the USB 512x16-bit SRAM section.

I've attached a screen shot from a USB protocol analyzer that shows the garbage data. Has anyone seen this before?

#vcp #usb #stm32l0 #cdc #murder-by-aggregate

tsuneo · ‎2015-12-28

Posted on December 29, 2014 at 05:56

> For the STM32L0 project I am using the STCubeMX.

> .. Now if I try and transmit 123456789 I get 9 bytes of garbage. > .. and then write it to memory location 0x40006000 Sound like a problem around endpoint buffer assignment. STCubeMX (v4.50) doesn’t yet generate the code which assigns EP buffer for the CDC EPs. Manually add these code, as follows.

usbd_conf.c
#include ''usbd_cdc.h'' // <-- add this line for CDC_OUT_EP, CDC_IN_EP, CDC_CMD_EP macros
USBD_StatusTypeDef USBD_LL_Init (USBD_HandleTypeDef *pdev)
{ 
/* Init USB_IP */
/* Link The driver to the stack */
hpcd_USB_FS.pData = pdev;
pdev->pData = &hpcd_USB_FS;
hpcd_USB_FS.Instance = USB;
hpcd_USB_FS.Init.dev_endpoints = 8;
hpcd_USB_FS.Init.speed = PCD_SPEED_FULL;
hpcd_USB_FS.Init.ep0_mps = DEP0CTL_MPS_8;
hpcd_USB_FS.Init.phy_itface = PCD_PHY_EMBEDDED;
hpcd_USB_FS.Init.Sof_enable = DISABLE;
hpcd_USB_FS.Init.low_power_enable = DISABLE;
hpcd_USB_FS.Init.battery_charging_enable = DISABLE;
HAL_PCD_Init(&hpcd_USB_FS);
HAL_PCDEx_PMAConfig(pdev->pData , 0x00 , PCD_SNG_BUF, 0x18);
HAL_PCDEx_PMAConfig(pdev->pData , 0x80 , PCD_SNG_BUF, 0x58);
// <-- add these 3 lines
HAL_PCDEx_PMAConfig(pdev->pData , CDC_OUT_EP , PCD_SNG_BUF, 0x100); 
HAL_PCDEx_PMAConfig(pdev->pData , CDC_IN_EP , PCD_SNG_BUF, 0x140); 
HAL_PCDEx_PMAConfig(pdev->pData , CDC_CMD_EP , PCD_SNG_BUF, 0x180);
return USBD_OK;
}

Tsuneo

nlbutts · ‎2015-12-30

Posted on December 30, 2014 at 17:26

That worked!!! Thanks.

USB with the new STCubeMX seems horrible broke. How did you figure this one out?

bobseabrook9 · ‎2016-04-05

Posted on April 05, 2016 at 18:15

The current CubeMx generated USBD_LL_Init() is very different now, at least for the STM32F4

Does anyone have a simple robust example of a working USB CDC Device that builds upon the initialization generated by the lastest 2016 CubeMX version4.14 for the STM32F4.

I have managed to create a partly working STM32F407 USB CDC Device example with CubeMx and have manually added a few lines of code to transfer data IN to Host and OUT from Host. But, the code I have added is a poor first guess that is OK moving data from Device(firmware) to Host(Windows), but hangs the interface after transferring several bytes from the Host to the Device.

I have attached a detailed pdf showing a procedure to generate a USB CDC Device on an STM32F407VGT6 with a few extra lines of code added to test data transfer. The code is added in steps 17 and The procedure uses the SW4STM32 IDE (System Workbench for STM32, from AC6). It creates the project from scratch - step by step - so no incompatible project files. The target board is an STM32F4Discovery(using STM32F407VGT6).

If anyone can improve the few lines of code I have added please reply here with the improvement. Meanwhile I am working on the problem by comparing the incomplete cubeMX generated code with VCP example in the 'other' very different ST USB library that is documented by UM1021 - vintage November 2

EDIT

I have finally located Standalone_CDC inside the STM32Cube_FW_F4_V1.0 STM324xG Applications USB_Device folder and hoping to adapt it for the STM32F4Discovery board thanks to post by qwer.asdf in another thread.

________________

Attachments :

post-cdc1-CORRECTION.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0dW&d=%2Fa%2F0X0000000bcY%2F.TKJy8yFhK6g756pPF8SwVTOnin7OrM8dwUAsS2PYtc&asPdf=false

Walid FTITI_O · ‎2016-04-27

Posted on April 27, 2016 at 12:05

Hi seabrook.bob,

Refere to my recommendation at this

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/how%20to%20use%20the%20example%20CDC_Standalone%20for%20personal%20application&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902...

.

Share with us your project update/status.

-Hannibal-

bobseabrook9 · ‎2016-04-29

Posted on April 29, 2016 at 15:42

Update attached.

Much better but NOT robust!

After 1-to-300 message reply alternations the USB interface hangs.

Can anyone fix this?

There are only a few lines of code additional to CubeMX initialization.

Note: my project uses the STM32F407VGT6 on the STM32F4Discovery.

Since writing the attached pdf, My code in main.c now transmits a 4 byte message when something (256 bytes) is received from the host. This fails after 1-to-300+ message reply alternations. The attached pdf should suffice to demonstrate the problem.

Edit.

It is worrying thatAPP_TX_DATA_SIZE andAPP_RX_DATA_SIZE are only referenced to set the size of arrays. They are never referenced to check if data exceeds the array bounds. There are no ASSERT directives to ensure that the users settings of these defines are valid. Given that a comment says it is the user responsibility to set these defines, it might be good to comment some guidance what those values might be. PLEASE give the authors time to leave a trail of !!!!INTENT!!!! to SAVE time later. Finally it is unclear when size refers to capacity or content. It is great code, please grant the authors more time to advertise its greatness. Understanding the code is like understanding the intent of drivers with no brake lights or indicators in busy traffic. Intent. Intent. Intent. Intent. Intent. Intent. Intent.

________________

Attachments :

cdc-post2.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0bA&d=%2Fa%2F0X0000000bcX%2F1_um4.gVa7go_IDP1hvvW.OdznexALEY6Tt1A7EypJo&asPdf=false

Walid FTITI_O · ‎2016-04-29

Posted on April 29, 2016 at 20:23

Hi seabrook.bob,

I have got your feedback in the other thread.

-Hannibal-