Skip to main content
Visitor
October 16, 2026
Question

STM32F411CEU6 (WeAct Black Pill V3.0): USB DFU connects and erases flash but fails during programming; USART1 bootloader also fails to connect

Hardware and software

  • MCU: STM32F411CEU6

  • Board: WeAct Black Pill V3.0

  • IDE: STM32CubeIDE 2.2.0

  • Programming tool: STM32CubeProgrammer 2.21.0

  • Host OS: Windows 11

  • Application: Existing application built as an ELF and BIN file (approximately 69.11 KB)

  • Current programming method: JTAG/SWD, which works correctly

Board reference: https://stm32-base.org/boards/STM32F401CEU6-WeAct-Black-Pill-V3.0.html#Reset-button

The reference page describes the F401 version of the board; my board uses the STM32F411CEU6.

Objective

I want to program a fixed application binary (.bin) directly using STM32CubeProgrammer over USB DFU or UART, using the STM32's factory-programmed system-memory bootloader.

I am not developing a custom bootloader or implementing field firmware updates. The same application currently programs and runs correctly through JTAG/SWD.

1. USB DFU behaviour

I enter system-memory boot mode by holding BOOT0, pressing and releasing NRST, and then releasing BOOT0.

Windows detects the device through USB, and STM32CubeProgrammer identifies it using:

  • VID: 0x0483

  • PID: 0xDF11

CubeProgrammer connects successfully and identifies the target as an STM32F411xC/E with 512 KB of flash and a Cortex-M4 core.

I can also read flash successfully. For example, reading 1024 bytes from 0x08000000 succeeds.

However, programming the application fails.

The relevant log is:

Opening and parsing file: CSL2401.bin
Memory Programming ...
File : CSL2401.bin
Size : 69.11 KB
Address : 0x08000000

Erasing memory corresponding to segment 0
Erasing internal memory sectors [0 4]
Download in Progress:
Error: Write failed at address: 0x08008000
Error: failed to download Sector[0]
Error: failed to download the File
Disconnected from device.

The same failure occurs when attempting to program the ELF file.

The failure is consistently reported at 0x08008000, which is the beginning of Sector 2 on the STM32F411.

2. Flash protection and hardware checks

I checked the option bytes in STM32CubeProgrammer:

  • RDP is 0xAA (Level 0).

  • WRP0–WRP7 are off.

  • SPRMOD is unchecked, so PCROP mode is disabled.

Flash reads and sector erase operations appear to work through USB DFU, but programming fails.

I also programmed the same application through JTAG/SWD. Programming and execution work correctly using that method.

This suggests that the application binary and normal flash programming path work through SWD, although I have not independently verified the cause of the USB DFU failure.

3. USART1 ROM bootloader behaviour

I also attempted to use the factory ROM bootloader through USART1.

The wiring is:

USB-to-TTL adapter       STM32F411CEU6

TX PA10 (USART1_RX)
RX PA9 (USART1_TX)
GND GND

The USB-to-TTL adapter is connected to COM10. The target is powered separately, and the adapter's VCC is not connected.

I tried the following STM32CubeProgrammer UART configuration:

Port          COM10
Baud rate 115200, then 9600
Parity Even
Data bits 8
Stop bits 1
Flow control None

I used the same BOOT0/NRST sequence to enter system-memory boot mode, but CubeProgrammer reports:

Error: Activating device: KO.
Please verify the boot mode configuration
and check the serial port configuration.
Reset your device then try again.

The COM port opens successfully, but the initial bootloader connection fails. I have not yet independently verified the UART synchronization-byte exchange or identified the USB-to-TTL adapter's exact chipset.

4. Summary of results

Test Result
Program application through JTAG/SWD Works
Enter USB DFU mode Works
Windows USB DFU enumeration Works
CubeProgrammer USB connection and target identification Works
Read internal flash through USB DFU Works
Erase flash sectors through USB DFU Appears to work
Program ELF through USB DFU Fails at 0x08008000
Program BIN through USB DFU Fails at 0x08008000
Connect to USART1 ROM bootloader Fails with Activating device: KO
RDP / WRP / PCROP checks No protection identified

Questions

  1. Are there any known STM32F411CEU6 ROM bootloader limitations or issues that could explain successful USB DFU connection, flash read and erase, but failure during programming?

  2. Is there a recommended diagnostic procedure to identify why the DFU write operation fails at 0x08008000, given that the same application programs correctly through SWD?

  3. Could the board's 25 MHz HSE or another hardware/clock consideration affect the ROM USB DFU programming operation?

  4. For the USART1 bootloader, are there additional boot-mode, pin-configuration or electrical checks I should perform beyond the standard BOOT0/NRST sequence and PA9/PA10 wiring?

  5. Is there a way to obtain more detailed error information from the ROM bootloader or STM32CubeProgrammer to distinguish a flash programming error from a transport/protocol issue?

I would appreciate any suggestions for further tests or documentation relevant to this specific MCU and board.

Thank you.

15 replies

Andrew Neil
Super User
October 16, 2026

Note that Black Pill is not an ST product; it might not even have a genuine STM32.

Therefore, you need to go to the board manufacturer for support.

 

I would appreciate any suggestions for further tests or documentation relevant to this specific MCU ...

All ST documentation for a genuine STM32F411CEU6 can be found on the Product Page:

https://www.st.com/en/microcontrollers-microprocessors/stm32f411ce.html

 

… and board

As noted, it’s not an ST board - so you’ll need to go to the manufacturer for that.

For best results, you should use a genuine ST board; eg, NUCLEO-F411RE:

https://www.st.com/en/evaluation-tools/nucleo-f411re.html

via: https://www.st.com/en/microcontrollers-microprocessors/stm32f411ce.html#tools-software

 

That way you will get a fully-supported board - and it comes with a genuine ST-Link built in

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Maxime MARCHETTO
ST Community Manager
October 16, 2026

Hello ​@IoTDevCellcomm    

The product you are using is a clone of a genuine ST product. 

To get the support you need, please contact the third party you purchased this product from.  

For assurance of buying authentic ST products, we recommend purchasing exclusively through our official distributors, which you can find listed here: ST Official Distributors.  

Best regards,  
Maxime

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question.
AScha.3
Super User
October 16, 2026

​@Maxime MARCHETTO ,

How you know , its not STM cpu ?

  • Hersteller (VID): 0x0483 (STMicroelectronics) [1]
  • Produkt-ID (PID): 0xDF11 (STM Device in DFU Mode) [1]
  • identifies it as STM device in dfu mode

So why ?

If you feel a post has answered your question, please click on " Best Answer ".
Andrew Neil
Super User
October 16, 2026

​identifies it as STM device in dfu mode

It only shows that it’s using ST’s identifiers ...

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Visitor
October 16, 2026

Thanks for your response

.
We purchased Black pill board for POC purpose
Now we are moving ahead with customized PCB for our real product using STM32F411CEU6 MCU

Once it is ready, we will take trials and if we are stuck then will reach out here

Andrew Neil
Super User
October 16, 2026

We purchased Black pill board for POC purpose

I would recommend the Nucleo board for that.

 

If your question is now answered, please mark the solution on the post which provided the answer 

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.