1

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://learn.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 those windows machines where the device is not found the function SetupDiEnumDeviceInterfaces(info, NULL, &Guid, devIndex, &ifData) returns false 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 any one 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.

alex_ER
  • 31
  • 1
  • 3
  • What error code is returned by `GetLastError` when the setup call fails? – 1201ProgramAlarm Dec 08 '20 at 21:01
  • Does it show up with WMI? (powershell and type: Get-WMIObject Win32_SerialPort), if yes, maybe you could get the port using wmi interface in your code and use CreateFile/WriteFile to send the file. – Júlio César Schincariol Filho Dec 08 '20 at 22:51
  • `the device on some windows PCs can’t be found` For some pcs, you may need to use `SetupDiGetDeviceProperty` to retrieve device instance properties that exist in the system but do not belong to any known setup class. See [this part](https://learn.microsoft.com/en-us/windows/win32/api/setupapi/nf-setupapi-setupdigetclassdevsw#examples). – Strive Sun Dec 09 '20 at 07:26
  • @1201ProgramAlarm : ```GetLastError``` called after ```SetupDiGetClassDevs(&Guid, NULL, NULL, DIGCF_PRESENT | DIGCF_INTERFACEDEVICE)``` returns 0. Calling ``GetLastError``` after ```SetupDiEnumDeviceInterfaces(info, NULL, &Guid, devIndex, &ifData)``` returns ```259``` which translates to ```ERROR_NO_MORE_ITEMS``` according to this [errorcode documentation](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-). – alex_ER Dec 09 '20 at 13:10
  • @Júlio César Schincariol Filho : the device is listed in the output of the power shell command ```Get-WMIObject Win32_SerialPort)``` as long as it is not in the DfuSe-mode. Once the upgrade process has been triggered (as described in point 3.) of my initial post) the device is set in the DfuSe-mode and is no longer part of the output of the powershell command ```Get-WMIObject Win32_SerialPort)```. – alex_ER Dec 09 '20 at 13:21
  • @Strive Sun - MSFT : Thanks for your comment. Did I understand you right that you refer to "Example 5: Build a list of all devices that are present in the system but do not belong to any known device setup class" on the page you linked? If yes, could it be that there is a typo in the example code: my compiler does not know the function ```SetupDiGetDeviceProperty``` but instead ```SetupDiGetDevicePropertyW```. Is the latter the proper name or is this a different function? Please excuse my maybe not so smart question. I am rather new to c++ programming. – alex_ER Dec 09 '20 at 20:11
  • Yes. `SetupDiGetDevicePropertyW` is Unicode version. You can learn more from [Unicode in the Windows API](https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api). – Strive Sun Dec 10 '20 at 02:03
  • If you call `SetupDiGetDevicePropertyW` successfully, please check the `ClassGuid` value which located in [DeviceInfoData](https://learn.microsoft.com/en-us/windows/win32/api/setupapi/ns-setupapi-sp_devinfo_data) structure. And see if it is the same as the defined `Guid` value. – Strive Sun Dec 10 '20 at 02:20

0 Answers0