Fail to find serial connected ST microcontroller device (integrating a STM32L475VET6) via windows api functions (SetupDiGetClassDevs, SetupDiEnumDeviceInterfaces) on some windows 7/8/10 systems

[AGroe.1]

Hello,

I maintain the firmware und update software of a device that integrates a ST microcontroller (STM32L475VET6). The update software is implemented in javascript and c++. In windows 7/8/10 the update software sometimes fails to find the device utilizing c++ windows API functions while the device is in STM DfuSe-mode. The details are described below:

The update program process is as follows:

1.) The device integrating the STM32L475VET6 microcontroller is connected to the PC via USB cable.

2.) A javascript-program is used to establishes a serial connection to the device. If triggered by the user the java-script program sends a json-command via serial connection to the device that restarts the device with starting the bootloader. After reset, the device will be in STM DfuSe-mode.

3.) The javascript program calls a C++ program that shall find the device and transfer a new firmware binary to the device.

The failure occurs in step 3 where the device on some windows PCs can’t be found. In detail:

3.1) A device info set „info“ of connected devices is created by calling the windows API function: "SetupDiGetClassDevs(&Guid, NULL, NULL, DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);“.

This function call returns a valid device information set handle (see https://docs.microsoft.com/en-us/windows-hardware/drivers/install/device-information-sets).

3.2) In a for-loop the interfaces of the device info set are enumerated by calling the windows API function "SetupDiEnumDeviceInterfaces(info, NULL, &Guid, devIndex, &ifData)", starting with devIndex = 0.

On windows machines where the device is not found the function "SetupDiEnumDeviceInterfaces(info, NULL, &Guid, devIndex, &ifData)" returns "false" for for "devIndex = 0" and the program terminates.

A workaround for that failure on some windows 7/8 systems has been to install the STM32 Virtual COM Port Driver 1.5.0 (https://www.st.com/en/development-tools/stsw-stm32102.html). However, this driver cannot be installed on all windows 7/8 PCs as the stm32 virtual com port drivers are not signed and on some machines installing unsigned drivers cannot be enabled.

With windows 10 this workaround is not an option as the drivers STM32 Virtual COM Port Driver 1.5.0 are explicitly not for Windows 10. Moreover, it was observed that the described failure occurred on one windows 10 machine while it did not occur on another windows 10 machine utilizing the same serial port driver (SERIAL.SYS (10.0.19041.1, 88,50 KB (90.624 Bytes), 07.12.2019 10:07)). Both systems had the same windows built installed (Windows 10 Pro, Version 10.0.19041 Build 19041).

I would be thankful for information of anyone that has experienced fails in attempts to find stm-devices in dfu-mode under windows and any hints pointing to the cause of the failure?

Thanks in advance 

A.

[Pavel A.]

It's hard to tell why a custom C++ program does not find the device.

When SetupDiEnumDeviceInterfaces returns false, does it by chance call GetLastError to understand why?

On machines where the device is not found : do you see the device in Device Manager, either as DFU or its operation mode (VCP?)

What is the version of usbser.sys?

The serial.sys version is not relevant at all because the device in question is actually USB,

-- pa

[AGroe.1]

On a machine where the upgrade process fails the behavior is as follows:

As long as the device is not in DFU-mode it appears in the device manager in the category "Ports (Com & LPT)" and the associated driver is C:\windows\system32\DRIVERS\usbser.sys (Fileversion: 10.0.19041.1, Win Build: 160101.0800).

When it is set to DFU-mode (at point 3. of my initial post) the device appears in the device manager in the category "other devices". The device status in the device details reports: "The drivers for this device are not installed. (Code 28). There are no compatible drivers for this device. To find a driver for this device, click Update Driver."

However, the windows built in update driver function fails in this case.

[CHossack]

hi,

I have the same problem. We're using a stm32g474 with USB in a product, that we allow infield upgrades using our custom tool. It just checks that it's the correct firmware before switching to DFU mode. The code fails to detect any device interfaces when calling SetupDiEnumDeviceInterfaces() as stated above on my windows 10 PC.

All of this code is based on "DfuSe USB device firmware upgrade (UM0412)", which also doesn't detect my DFU device. But since this code is no longer supported I doubt ST will fix it. Instead they recommend using their STM32CubeProgrammer (which does work).

But that's a real pain asking our customers to install our tool and ST's tool, and then getting our tool to silently run ST's tool, and provide a progress bar to the user. But I guess that's what I'm going to have to do ;-(

On St's website it states

• "Starting from Windows® 10, the STSW-STM32102 driver is no more adequate and the usage of the native inbox driver is recommended"

Can we switch to use the native inbox-driver in our custom tool, are there any DFU examples? Or is there any recommended way to include ST's tool in our installer, and calling it silently?

cheers

Chris

[AGroe.1]

Sehr geehrte Damen und Herren,
vielen Dank für Ihre Nachricht. Ich bin ab dem 15.02.21 nicht mehr im Büro und kann Ihre Anfrage nicht beantworten.
Bitte wenden Sie sich ab dem 15.02.21 mit Ihrem Anliegen an Herrn Dr. Rinat Tyumenev (rinat@interherence.com).
Dear Sir or Madam,
thank you for your email. As of the 15th ofFebruary 2021 I am out of office and will not be able to respond to your inquiry.
From 15th of February 2021, please contact Dr. Rinat Tyumenev (rinat@interherence.com) with your request.