Problem (solved?) with USB CDC

infor · ‎2017-05-20

Posted on May 20, 2017 at 16:58

While working on a project based on STM32F202VG, I experienced intermittent and unexplainable problems with USB used with CDC class.

Sometimes everything was working perfectly, but after power-cycling the board or the PC, opening the COM port failed with a Windows 'Incorrect parameter' error.

After an in-depth analysis, I discovered a difference between correc' and incorrect initialization.

The two sequences are identical up to a certain point. Then, there is a difference in a setup packet from the board to the PC.

See the transcript from Device Monitoring Studio:

GOOD

Control Transfer (UP), 2017-05-14 18:15:21,8528439 +0,0001177. (1. Device: STMicroelectronics Virtual COM Port (COM13)) Status: 0x00000000

Pipe Handle: Control Pipe

00 00 00 00 00 00 00

BAD

Control Transfer (UP), 2017-05-14 18:14:31,2491097 +0,0001700. (1. Device: STMicroelectronics Virtual COM Port (COM13)) Status: 0x00000000

Pipe Handle: Control Pipe

80 64 06 2B 3E 50 1B

The only difference is that the unused part of the packet does contain zeroes, or does not.

As a blind test, I did this change to the CubeMX file usbd_cdc.c, row 516 :

...

pdev->pClassData = USBD_malloc(sizeof (USBD_CDC_HandleTypeDef));

memset(pdev->pClassData,0,sizeof(USBD_CDC_HandleTypeDef)); // THIS LINE WAS ADDED

if(pdev->pClassData == NULL)

...

After this change, CDC works everytime the board is turned on.

If the patch is removed, the intermittent problem returns.

Nonetheless, i cannot consider the bug as fixed. I don't understand if this patch solves something, and why...but after all I am not an USB expert !!

Can someone shed a light on this issue?

If needed, I have the full trasncripts of the 'good' and 'bad' USB initialization sequence.

I am using STM32Cube FW_F2 V1.6.0

#cube-mx #usb_cdc

waclawek.jan · ‎2017-05-22

Posted on May 22, 2017 at 12:14

The two sequences are identical up to a certain point. Then, there is a difference in a setup packet from the board to the PC.

Which packet exactly? Can you show us the whole packet?

JW

infor · ‎2017-05-22

Posted on May 22, 2017 at 21:25

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=0680X000006I6sO&d=%2Fa%2F0X0000000bx6%2F9zl7ciUm0zqYibGJ331jkb63pwNbvfueQc5oZWWptTU&asPdf=false

waclawek.jan · ‎2017-05-22

Posted on May 23, 2017 at 00:37

Sorry, I am not familiar with the tool you are using and simply can't figure out what all those data are supposed to mean. Apparently, the packets are partially decoded - with the standard requests it makes some sense, but then I don't know how to cathegorize the packets in question .

Isn't there an 'unparsed, raw data' or similar setting in your tool?

JW

infor · ‎2017-05-23

Posted on May 23, 2017 at 21:30

I'll try Tomorrow. Perhaps there is such a possibility. In this case I can repeat the sequences and post them here.

If the tool is unable to provide raw data, can you please suggest a different tool?

Besides... it seems that my patch really fixed the problem. The big question is still 'why'....

infor · ‎2017-05-25

Posted on May 25, 2017 at 21:52

I think I've identified the problem.

The issue comes from a wrong answer to the PC's request GET_CODING_LINE.

In the ''bad'' session, the firmware fills the payload with random data, and this leads to further problems. In facts, the COM port is enumerated, but no communication takes place.

Filling the payload to zeroes is also wrong, but somehow the PC can manage it, and sends a SET_CODING_LINE.

The origin of the problem is CDC_Control_FS() in usbd_cdc_if.c

This function manages CDC class requests... but in facts does nothing. A switch enumerates the various requests,

but case statements are empty!!!

The code in the function is classified as ''user code'', so you are supposed to write it. Nonetheless, this is a bug in the CubeMX.

Why not putting a #warning or a TODO in the switch, instead than wasting customers' time?!

Anyway, you may put some code in the function. For example writing:

case CDC_GET_LINE_CODING:

{

uint32_t speed = 115200;

uint8_t databits = 8;

length = 7;

memcpy(pbuf,&speed,4);

pbuf[4] = 0;

pbuf[5] = 0;

pbuf[6] = 8;

}

break;

Automagically solved my issue.

This is the ''good'' session

I will open a bug report in another message.

Imen.D · ‎2017-05-26

Posted on May 26, 2017 at 11:07

Hi

Scarpi.Giuseppe.002

,

Thank you again for your contribution. Your issue is reported internally for further investigation.

https://community.st.com/0D50X00009XkfnmSAB

Regards

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

jaafarkh · ‎2023-06-20

thanks @infor this solved my problem on Windows 10. The problem is also associated with the type of the usb hardware. On Windows 7, there is no problem, on Windows 10, the problem exist, I used two different laptops thinkpad and hp, both produced parameter is incorrect error. On Windows 11 with desktop machine, there is no problem. When I applied your patch to usbd_cdc_if.c file, the problem disappeared. I hope ST provide updated middleware files.