2025-01-28 08:50 AM - edited 2025-01-29 09:05 AM
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
2025-01-26 04:10 PM - edited 2025-01-26 04:11 PM
> 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!
2025-01-29 07:29 AM
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.
2025-01-29 07:54 AM - edited 2025-01-29 07:59 AM
@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?
2025-01-29 09:23 AM
@SofLit 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...
2025-01-29 09:33 AM
@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?
2025-01-29 10:20 AM - edited 2025-01-29 10:26 AM
@Shlapunov.Nicolai wrote:
As for using Nucleo... how I suppose to fit it inside device on photos I posted? Rhetorical question.
To be honest as ST we don't support these * Pill boards for the reason I mentionned previously. Maybe you need to unsolder and solder another Genuine chip purchased from trusted distributer like mouser, arrow etc..
2025-01-30 04:11 AM
> As for using Nucleo... how I suppose to fit it inside device on photos I posted?
Of course, the NUCLEO have sometimes a different form factor, but they may not be used in end products (see Terms of Use, Restrictions and Warnings). A NUCLEO is therefore only intended for the development phase in the laboratory and is usually replaced later by a separate layout.
If you then obtain the MCUs from trustworthy sources (dealers such as Aliexpress are not among them), you will already have a lot fewer potential problems.
2025-01-30 04:19 AM
@Peter BENSCH wrote:A NUCLEO is therefore only intended for the development phase in the laboratory and is usually replaced later by a separate layout..
Indeed.
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?
2025-01-30 04:44 AM
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.
> Не зря СССР называли "страна советов"...
Это я ещё не знал ... ;)