WeAct BlackPill: Ocasional DFU problems in STM32CubeProgrammer on Windows 10

[Shlapunov.Nicolai]

Hi Everyone,

I have some problems with DFU on Windows 10. I use WeAct BlackPill boards based on STM32F411 MCU. This board has BOOT0 button which allow to update firmware using STM32CubeProgrammer and DFU mode.

Majority of the boards can be programmed in DFU mode using STM32CubeProgrammer with no issue. Recently I got couple boards that acts very weird: those boards enters DFU mode just fine, detects by STM32CubeProgrammer and able to connect, but as soon I try to erase or program those boards - STM32CubeProgrammer says "Connection lost" and that is it. After that those boards enters into DFU mode, STM32CubeProgrammer able to read serial number, but any attempt to connect failed:

 

 16:51:36 : STM32CubeProgrammer API v2.18.0 | Windows-64Bits 
 16:51:45 : UR connection mode is defined with the HWrst reset mode
 16:51:45 : USB speed : Full Speed (12MBit/s)
 16:51:45 : Manuf. ID : STMicroelectronics
 16:51:45 : Product ID : STM32 BOOTLOADER
 16:51:45 : SN : 337F33963134
 16:51:45 : DFU protocol: 1.1
 16:51:45 : Board : --
 16:51:45 : Device ID : 0x0431
 16:51:45 : UPLOADING OPTION BYTES DATA ...
 16:51:45 : Bank : 0x00
 16:51:45 : Address : 0x1fffc000
 16:51:45 : Size : 16 Bytes
 16:51:45 : UPLOADING ...
 16:51:45 : Size : 1024 Bytes
 16:51:45 : Address : 0x8000000
 16:51:45 : Read progress:
 16:51:45 : Error: Data read failed
 16:51:45 : Warning: Connection to device 0x431 is lost
 16:51:51 : Warning: Connection to device 0x431 is lost
 16:52:00 : Disconnected from device.
 16:52:00 : Disconnected from device.

 

If I use ST-Link to program those boards, I able to connect in DFU mode again... until I try to reprogram it. Then same problem with connection appears again.

I tried two different cables and three different laptops - same result.

But then I decided to try another PC with Windows 11 and it works! It works every single time on two different Windows 11 based laptops with no problems! STM32CubeProgrammer version is the same(2.18), so it is not that, it is something else. I wondering what it can be.

I really want this issue to be fixed, because I can't use those boards for my SmartPendant project to control CNC machines based on grblHAL controllers, since it will be impossible to update firmware under Windows 10, and even worse - attempt bricks device until it will be reprogrammed on Windows 11.

 

@Pavel A. wrote:

>  since it will be impossible to update firmware under Windows 10

Windows 11 works better than Win10. Sometimes newer is better. Support of Windows 10 will end in October anyway. Time to update!

---

I wondering why some people give advices that doesn't helps at all.Не зря СССР называли "страна советов"...

I make those devices and sell them to hobbyists like me who converting benchtop mills/lathes into CNC. They can use different OS and I have no control of it. I couldn't just say "Oh, you have a problem? Time to update!". Beside, I tried it on Windows. Will it have same problem on MacOS? On a Linux? I don't know. But what I do know there some problems with some of MCU, because some boards work and some don't. And those problems potentially can be fixed on STM32CubeProgrammer side since it works flawlessly on Windows 11.

And questions I want to be answered:

1) If it bug in MCU, does it affect anything beside DFU? Crushing CNC machine is not fun.

2) Will it be fixed in STM32CubeProgrammer?

 

P.S. I reposted it from there: https://community.st.com/t5/stm32-mcus-embedded-software/ocasional-dfu-problems-in-stm32cubeprogrammer-on-windows-10/m-p/765994/

since this is more appropriate section. You can delete original topic. <-- Threads merged

[Pavel A.]

>  since it will be impossible to update firmware under Windows 10

Windows 11 works better than Win10. Sometimes newer is better. Support of Windows 10 will end in October anyway. Time to update!

 

[mƎALLEm]

Hello,

Just to be clear. Most of Black/Blue (other colors) Pill don't contain a genuine STM32 chip. I suggest you to purchase a ST board instead. NUCLEO-F411RE is a choice.

[Andrew Neil]

---

@Shlapunov.Nicolai wrote:

Recently I got couple boards that acts very weird

---

That's another problem with these no-name cheap boards - there is no continuity of supply.

Though the boards may look the same, you have no guarantee that they actually are the same.

 

---

@Shlapunov.Nicolai wrote:

If I use ST-Link to program those boards

---

Is that a genuine ST-Link, or a clone?

 

---

@Shlapunov.Nicolai wrote:

I able to connect in DFU mode again... until I try to reprogram it. Then same problem with connection appears again

---

Sounds like a fault in the DFU bootloader, then?

[Shlapunov.Nicolai]

@mƎALLEm wrote:

Hello,

Just to be clear. Most of Black/Blue (other colors) Pill don't contain a genuine STM32 chip. I suggest you to purchase a ST board instead. NUCLEO-F411RE is a choice.

---

I am well aware of fake STM32F1 MCUs, but I did not found any information about fake STM32F411 MCUs. I purchased those board from WeAct Studio official store on AliExpress, link can be found on their GitHub page: https://github.com/WeActStudio/WeActStudio.MiniSTM32F4x1

They claimed that all ICs they using "are functional and original". They also have another boards with MCUs like STM32H743, STM32U585CIU6, STM32G474CEU6 and I don't think that fake versions of those MCUs exists.

As for using Nucleo... how I suppose to fit it inside device on photos I posted? Rhetorical question.

If you like, I am willing to mail board to ST(within the United States) for further investigation. I also can try to decapping one of MCU to check if it genuine, but don't know if 5W diode laser engraver will do the trick.

 

---

@Andrew Neil wrote:

---

 

---

Is that a genuine ST-Link, or a clone?

---

It is not, but it doesn't matter. This is how it works without ST-Link, in DFU mode only: if BlackPill has some code in it, it can be read on Windows 10. As soon memory erased - it can't connect anymore on Windows 10. But it can connect on Windows 11 and can be erased and programmed, after which it can be read on Windows 10 until another erase operation.

 

---

@Andrew Neil wrote:
Sounds like a fault in the DFU bootloader, then?

 

I am not so sure. Stm32CubeProgrammer the same, MCU is the same, then problem probably somewhere else, not in DFU bootloader itself. Different USB stack with different timeouts? Some timing issues? Crystal oscillator out of tolerances slightly? I don't know, it can be anything. I probably should to try use USB sniffer to check the difference...

[Andrew Neil]

---

@Shlapunov.Nicolai wrote:

---

As for using Nucleo... how I suppose to fit it inside device on photos I posted? Rhetorical question.

---

Use a Nucleo 32?

https://www.st.com/en/evaluation-tools/stm32-nucleo-boards/products.html?querycriteria=productId=LN1847$$1574=Nucleo-32

 

[Ozone]

When it works fine under Win11 but not Win10, this most probably excludes the board or the PC itself. I would have suspected power supply issues in this case.

But I have experienced quite a lot of issues with Windows in combination with certain USB / serial adapters, and it's associated drivers. Up to frequent bluescreens with certain devices, which work perfectly fine under Linux.
In this case, it might be also be the USB hub / host controller driver.

Usually a PC contains several such controllers, i.e. one for all the ports at the backside and one for the ports at the side or front. Thus just plugging it into another port might help, too.

And with a serial / USB adapter involved, you could experiment with the settings in "properties->advanced" in the device manager, like block size or timeout values.

> Не зря СССР называли "страна советов"...

Это я ещё не знал ... ;)

[Shlapunov.Nicolai]

Update: Connection doesn't work when I connect board directly to one of USB ports on laptop itself, but works if I connect it to dock station connected to the same laptop via USB-C. I also noticed that there different Verbosity Levels in STM32CubeProgrammer. I set it to 3, and when it doesn't work, this is what it shows:

 

08:41:54:866 : UR connection mode is defined with the HWrst reset mode
08:41:54:924 : DFU status = 0 : OK
08:41:54:925 : DFU state = 4 : dfuDNBUSY
08:41:54:925 : Status: 0, State: 4
08:41:54:925 : sending an abort request
08:41:54:925 : DFU status = 0 : OK
08:41:54:925 : DFU state = 2 : dfuIDLE
08:41:54:925 : setting the address pointer to address: 0x08000000
08:41:54:925 : DFU status = 0 : OK
08:41:54:925 : DFU state = 4 : dfuDNBUSY
08:41:54:926 : DFU status = 0 : OK
08:41:54:926 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:54:926 : Device Descriptor:
08:41:54:926 : |_bLength : 0x12
08:41:54:926 : |_bDescriptorType : 0x01
08:41:54:926 : |_bcdUSB : 0x0100
08:41:54:926 : |_bDeviceClass : 0x00
08:41:54:926 : |_bDeviceSubClass : 0x00
08:41:54:926 : |_bDeviceProtocol : 0x00
08:41:54:926 : |_bMaxPacketSize : 0x40
08:41:54:926 : |_idVendor : 0x0483
08:41:54:926 : |_idProduct : 0xdf11
08:41:54:927 : |_bcdDevice : 0x2200
08:41:54:927 : |_iManufacturer : 0x01
08:41:54:927 : |_iProduct : 0x02
08:41:54:927 : |_iSerialNumber : 0x03
08:41:54:927 : |_bNumConfigurations : 0x01
08:41:54:927 : Configuration Descriptor:
08:41:54:927 : |_bLength : 0x09
08:41:54:927 : |_bDescriptorType : 0x02
08:41:54:927 : |_wTotalLength : 0x36
08:41:54:927 : |_bNumInterfaces : 0x01
08:41:54:927 : |_bConfigurationValue : 0x01
08:41:54:927 : |_iConfiguration : 0x00
08:41:54:927 : |_bmAttributes : 0xc0
08:41:54:927 : |_bMaxPower : 0x32
08:41:54:927 : Interface Descriptor Alternate Settings: 0x00
08:41:54:927 : |_bLength : 0x09
08:41:54:927 : |_bDescriptorType : 0x04
08:41:54:927 : |_bInterfaceNumber : 0x00
08:41:54:928 : |_bAlternateSetting : 0x00
08:41:54:928 : |_bNumEndpoints : 0x00
08:41:54:928 : |_bInterfaceClass : 0xfe
08:41:54:928 : |_bInterfaceSubClass : 0x01
08:41:54:928 : |_bInterfaceProtocol : 0x02
08:41:54:928 : |_iInterface : 0x04
08:41:54:928 : Interface Descriptor Alternate Settings: 0x01
08:41:54:928 : |_bLength : 0x09
08:41:54:928 : |_bDescriptorType : 0x04
08:41:54:928 : |_bInterfaceNumber : 0x00
08:41:54:928 : |_bAlternateSetting : 0x01
08:41:54:928 : |_bNumEndpoints : 0x00
08:41:54:928 : |_bInterfaceClass : 0xfe
08:41:54:928 : |_bInterfaceSubClass : 0x01
08:41:54:928 : |_bInterfaceProtocol : 0x02
08:41:54:928 : |_iInterface : 0x05
08:41:54:928 : Interface Descriptor Alternate Settings: 0x02
08:41:54:928 : |_bLength : 0x09
08:41:54:929 : |_bDescriptorType : 0x04
08:41:54:929 : |_bInterfaceNumber : 0x00
08:41:54:929 : |_bAlternateSetting : 0x02
08:41:54:929 : |_bNumEndpoints : 0x00
08:41:54:929 : |_bInterfaceClass : 0xfe
08:41:54:929 : |_bInterfaceSubClass : 0x01
08:41:54:929 : |_bInterfaceProtocol : 0x02
08:41:54:929 : |_iInterface : 0x06
08:41:54:929 : Interface Descriptor Alternate Settings: 0x03
08:41:54:929 : |_bLength : 0x09
08:41:54:929 : |_bDescriptorType : 0x04
08:41:54:929 : |_bInterfaceNumber : 0x00
08:41:54:929 : |_bAlternateSetting : 0x03
08:41:54:929 : |_bNumEndpoints : 0x00
08:41:54:929 : |_bInterfaceClass : 0xfe
08:41:54:929 : |_bInterfaceSubClass : 0x01
08:41:54:929 : |_bInterfaceProtocol : 0x02
08:41:54:929 : |_iInterface : 0x07
08:41:54:930 : Functional Descriptor :
08:41:54:930 : |_bLength : 0x09
08:41:54:930 : |_bDescriptorType : 0x21
08:41:54:930 : |_bmAttributes : 0x0b
08:41:54:930 : |_wDetachTimeOut : 0xff
08:41:54:930 : |_wTransferSize : 0x0800
08:41:54:930 : |_bcdDFUVersion : 0x011a
08:41:54:930 : USB speed : Full Speed (12MBit/s)
08:41:54:930 : Manuf. ID : STMicroelectronics
08:41:54:930 : Product ID : STM32 BOOTLOADER
08:41:54:930 : SN : 337F33963134
08:41:54:930 : DFU protocol: 1.1
08:41:54:930 : Board : --
08:41:54:930 : Device ID : unknown
08:41:54:930 : DFU status = 0 : OK
08:41:54:930 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:54:930 : Status: 0, State: 5
08:41:54:930 : setting the address pointer to address: 0x08000000
08:41:54:930 : DFU status = 0 : OK
08:41:54:931 : DFU state = 4 : dfuDNBUSY
08:41:54:931 : DFU status = 0 : OK
08:41:54:931 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:54:931 : DFU status = 0 : OK
08:41:54:931 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:54:931 : Status: 0, State: 9
08:41:54:931 : sending an abort request
08:41:54:931 : DFU status = 0 : OK
08:41:54:931 : DFU state = 2 : dfuIDLE
08:41:54:931 : setting the address pointer to address: 0x08000000
08:41:54:931 : DFU status = 0 : OK
08:41:54:931 : DFU state = 4 : dfuDNBUSY
08:41:54:931 : DFU status = 0 : OK
08:41:54:931 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:54:931 : DFU status = 0 : OK
08:41:54:931 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:54:931 : Status: 0, State: 5
08:41:54:931 : setting the address pointer to address: 0x1fffc008
08:41:54:931 : DFU status = 0 : OK
08:41:54:932 : DFU state = 4 : dfuDNBUSY
08:41:54:932 : DFU status = 0 : OK
08:41:54:932 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:54:932 : receiving packet nbr: 0
08:41:54:932 : DFU status = 0 : OK
08:41:54:932 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:54:932 : sending an abort request
08:41:54:932 : DFU status = 0 : OK
08:41:54:932 : DFU state = 2 : dfuIDLE
08:41:54:932 : UpLoading data
08:41:54:932 : DFU status = 0 : OK
08:41:54:932 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:54:932 : Database: Config 0 is active.
08:41:54:932 : DFU status = 0 : OK
08:41:54:932 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:54:932 : Status: 0, State: 9
08:41:54:932 : sending an abort request
08:41:54:932 : DFU status = 0 : OK
08:41:54:932 : DFU state = 2 : dfuIDLE
08:41:54:932 : setting the address pointer to address: 0x08000000
08:41:54:932 : DFU status = 0 : OK
08:41:54:932 : DFU state = 4 : dfuDNBUSY
08:41:54:933 : DFU status = 0 : OK
08:41:54:933 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:55:115 : Status: 0, State: 9
08:41:55:115 : sending an abort request
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 2 : dfuIDLE
08:41:55:115 : setting the address pointer to address: 0x08000000
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 4 : dfuDNBUSY
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:115 : UPLOADING OPTION BYTES DATA ...
08:41:55:115 : Bank : 0x00
08:41:55:115 : Address : 0x1fffc000
08:41:55:115 : Size : 16 Bytes
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:115 : Status: 0, State: 5
08:41:55:115 : setting the address pointer to address: 0x1fffc000
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 4 : dfuDNBUSY
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:115 : receiving packet nbr: 0
08:41:55:115 : DFU status = 0 : OK
08:41:55:115 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:115 : sending an abort request
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 2 : dfuIDLE
08:41:55:116 : UpLoading data
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:55:116 : UPLOADING OPTION BYTES DATA ...
08:41:55:116 : Bank : 0x00
08:41:55:116 : Address : 0x1fffc000
08:41:55:116 : Size : 16 Bytes
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:55:116 : Status: 0, State: 9
08:41:55:116 : sending an abort request
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 2 : dfuIDLE
08:41:55:116 : setting the address pointer to address: 0x1fffc000
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 4 : dfuDNBUSY
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:116 : receiving packet nbr: 0
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:116 : sending an abort request
08:41:55:116 : DFU status = 0 : OK
08:41:55:116 : DFU state = 2 : dfuIDLE
08:41:55:116 : UpLoading data
08:41:55:116 : DFU status = 0 : OK
08:41:55:117 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:55:117 : UPLOADING ...
08:41:55:117 : Size : 1024 Bytes
08:41:55:117 : Address : 0x8000000
08:41:55:117 : Read progress:
08:41:55:117 : DFU status = 0 : OK
08:41:55:117 : DFU state = 9 : dfuUPLOAD-IDLE
08:41:55:117 : Status: 0, State: 9
08:41:55:117 : sending an abort request
08:41:55:117 : DFU status = 0 : OK
08:41:55:117 : DFU state = 2 : dfuIDLE
08:41:55:117 : setting the address pointer to address: 0x08000000
08:41:55:117 : DFU status = 0 : OK
08:41:55:117 : DFU state = 4 : dfuDNBUSY
08:41:55:118 : DFU status = 0 : OK
08:41:55:118 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:118 : receiving packet nbr: 0
08:41:55:118 : DFU status = 0 : OK
08:41:55:118 : DFU state = 5 : dfuDNLOAD-IDLE
08:41:55:118 : sending an abort request
08:41:55:118 : DFU status = 0 : OK
08:41:55:118 : DFU state = 2 : dfuIDLE

 

 

 

 08:41:55:118 : UpLoading data
 08:41:55:119 : libusb control transfer error [-9] : LIBUSB_ERROR_PIPE 
 08:41:55:119 : Error: Data read failed
 08:41:55:245 : Warning: Connection to device 0x431 is lost
 08:42:00:459 : Warning: Connection to device 0x431 is lost
 08:42:09:606 : Disconnected from device.
 08:42:09:647 : Disconnected from device.

 

 I probably should done it earlier. Search this error shows that I am not alone:

Error - libusb control transfer error [-9] : LIBUSB_ERROR_PIPE

STM32CubeProgrammer 2.14.0 firmware update error over USB in Windows 10 64 bit

STM32CubeProgrammer DFU instable

I highly doubt that everyone in those topics has fake MCUs. I assume ST will not resolve this issue.

 

@Andrew Neil wrote:

---

It seems that @Shlapunov.Nicolai has the PCB design resources - so why not just put the SMT32 straight onto the PCB? Why the plug-in board at all?

---

It is an hobby project, it started with all off the shelf modules. Then I decided to make a board to make it smaller. Initial idea was to use BlackPill connected to the board which will allow to replace it if it will be damaged, but turns out that while round connectors smaller than regular squire ones, it still make device too thick. My board contains only two layers, BlackPill has more. I am not sure if it can be done in two layers. More layers - more expensive board. Then placement fees, other parts cost and with volume of 10-30 boards it just doesn't give any benefits for this hustle.

And even if I'll do all this, when something will go wrong, some ST Employee probably will say "LCSC and JLCPCB is Chinese companies, may be they sourced fake STM32s" :D

[mƎALLEm]

Hello,

ST resources are dedicated to supporting genuine ST products. We are not committed to ensuring that clones/fakes work properly with the firmware we provide.

Thank you for your understanding.