Possible STM32 USB Virtual Com Port driver bug on Windows 10

[CH1]

Hey People,

I am using an STM32F446RE in a product with a custom board and have been having some issues with the USB virtual com port communicating with NI-MAX. It is a very similar issue as to what is described in this post in the NI Forums.

https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Connect-STM32-via-USB-using-virtual-COM-port/td-p/3750838?profile.language=en

Setup is

System workbench

STM32Cube 5.3 with STM32Cube STm32F4 library 1.24.1

NI-Max Visa 18.5

In windows 10 I can communicate with the board using a terminal with no problems at all but NI-Max sees it as an unknown device. In windows 7 NI-Max can communicate with it normally with no issues.

I have tried old versions of the HAL, I have tried variations of the hardware. I have also tried projects that only run USB and nothing else. I cannot get it to work reliably on windows 10.

The forum post suggests that it might be an issue with the VCP drivers for windows 10 but I am not sure how to verify if this is the case.

As support is ending for windows 7 we are upgrading all our machines to windows 10. So we need to find a solution that works on windows 10

Thanks for your help

[CH1]

Hey Guys,

Is there any noise on this. Not having any luck trying to find a solution.

[Bob S · Accepted solution]

In your STM32 code look in usbd_cdc_if.c for CDC_SET_LINE_CODING and CDC_GET_LINE_CODING cases. There needs to be code to save the settings from the "set line" command, and return those saved settings in the "get line" command. Most HAL libraries don't have that code. If you search the forums for CDC_SET_LINE_CODING you should find examples of this. There is a USBD_CDC_LineCodingTypeDef in usbd_cdc.h that defines the data used in these commands.

[CH1]

Hi Bob,

Thanks for your reponse. Just managed to get the time to test it and you were correct, its working well now.

The fact that it worked on windows 10 with a terminal had me looking in the wrong direction.

[JoniS]

It does only partially work with some terminals without line codings set, perhaps those use their own low level drivers for comport, instead of the one .net provides.

If you spam data fast enought without the linecodings, you crash all those terminal softwares which seem to work othervice.

[mcdino.5338840562911753E12]

How did you solve the problem? Which codes did you write under the CDC_SET_LINE_CODING and CDC_GET_LINE_CODING cases? Thanks for sharing.

[Bob S]

Did you search these forums for CDC_SET_LINE_CODING as I suggested in my answer? At least one of the threads that shows up has sample code.

[JoniS]

In short you cache the line codings values you get from remote device, then send those same values back when requested.​ As Bob did mention you will find the code for that inside these forums, aswell as from many GitHub repositorys.