Check BOOT0 and the upload method. Serial upload needs BOOT0 high for the upload, then low to run.
What the message means
The board has no USB bootloader on many clones. It needs a programmer, or the serial bootloader with the right jumper positions.
Fix it in this order
- Choose the upload method in the IDE that matches your hardware, such as ST-Link or serial.
- For serial upload set BOOT0 to 1, press reset, upload, then set BOOT0 back to 0 and reset.
- Connect an ST-Link correctly: SWDIO, SWCLK, GND and 3.3 V.
- Check the chip: some clones carry a different chip with another ID.
- Power the board from 3.3 V or USB, not both with other supplies.
- Install the driver for your programmer.
Why it happens
The STM32F103 on a Blue Pill has a serial bootloader in ROM, reached on USART1 (PA9 and PA10) when BOOT0 is high at reset. It has no USB DFU bootloader in ROM, so a Blue Pill that appears over USB has had a separate bootloader written to its flash first. A board with a blank or damaged flash will not enumerate over USB at all, and needs a serial adapter or an ST-Link.
Many boards sold as Blue Pills carry clone chips whose ID differs from the genuine part, which can make the upload tool reject them. If the tool reports an unexpected ID, check the chip marking and try the tool’s option for that chip before assuming the wiring is bad.
If you see this, do this
| You see | Do this |
|---|---|
| Upload works but the sketch does not run | BOOT0 still high. |
| Chip not found | Wiring, power or clone ID. |
Related
avrdude not responding, board not detected.
Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.
Why this happens
The STM32F103 chip has a built-in serial bootloader in system memory. It starts only if the BOOT0 pin is high when the chip resets, and it listens on USART1, which uses PA9 for transmit and PA10 for receive. With BOOT0 low, the chip runs the program in flash instead. A Blue Pill has no USB bootloader in ROM, so a board that shows up over USB has a bootloader that someone wrote to its flash earlier.
That explains the two usual failures. If BOOT0 stays high after a successful upload, the chip keeps entering the serial bootloader and your sketch never runs. If the flash is blank or the wrong upload method is chosen, nothing answers the tool, which then reports that the device cannot be found.
How to confirm the cause
- Check the position of the BOOT0 and BOOT1 jumpers. For serial upload, BOOT0 is 1 and BOOT1 is 0. For running the sketch, BOOT0 is 0.
- Wire a USB-serial adapter: adapter TX to PA10, adapter RX to PA9, grounds together. A swapped pair is a very common fault.
- With an ST-Link, run the probe command of the tool you use. If the probe sees the chip and its flash size, the wiring and the programmer are right.
- Read the chip marking and the ID the tool reports. A clone may report an unexpected ID.
- Measure 3.3 V on the board’s supply pin while the programmer is connected.
Worked example
Probing and writing with an ST-Link using the open-source command-line tools. Flash starts at address 0x08000000:
st-info --probe
st-flash write firmware.bin 0x8000000
# With a USB-serial adapter, BOOT0 = 1, then reset:
stm32flash -w firmware.bin -v -g 0x08000000 COM3
# Then BOOT0 = 0 and press reset to run the program.Common mistakes
- Leaving BOOT0 high and wondering why the sketch does not start.
- Connecting TX to TX instead of crossing the serial lines.
- Powering the board from the ST-Link and from USB at the same time.
- Mixing up SWDIO and SWCLK on the programming header.
- Using a 5 V adapter signal on a 3.3 V board.
If this did not fix it
- Reported USB problems on some boards come from the pull-up on the USB D+ line; check your board’s schematic or reports for the correct value.
- A chip that is a clone and needs a different option in the upload tool.
- Flash protection set on the chip; the tool will usually say so and offer to unlock it.