STM32Cubeprogrammer doesn't find STM32F103C8T6 blue pill board

I installed STM32CubeProrgrammer and my intention is to programm an STM32F103C8T6 (blue pill) board using the DFU interface. But STM32CubeProgrammer doesn't find a board as it seems.

How have you physically connected the Bluepill to the PC ? Using a USB cable to the USB socket on the Bluepill or via a USB/UART adapter to the header pins on the Bluepill ?
Have you loaded an additional bootloader onto the Bluepill or have you only the factory installed bootloader.
How have you set the two jumpers on the Bluepill.

@b707 was also looking at this. My recent experience is only with SWD / ST-Link V2 .

I have connected the blue pill via a USB cable to the ob board Micro USB socket. I cannot say exactly what bootloader I have on it. Maybe I reprogrammed it with the STM32duiono bootloader. How Can I revert to the factory bootloader?

Both boot jumpers are on "0"-Position.

Meanwhile I programmed the file generic_boot20_pc13.bin (using STM32CubeProgrammer) via UART to the device.

Connecting the USB cable and trying to detect the device via DFU/USB still fails.

You can burn a bootloader again if you connect it to a usb<>serial adapter and set boot0 to "1"

instructions: https://www.electrosoftcloud.com/en/stm32f103-bootloader-and-programming/

Thanks. While I was posting what I did - namely exactly that - your post dropped in :slight_smile:

Why do you start a new topic for similar subject?
I ask the moderator to merge it to one thread.

The topic of this thread is "STM32CubeProgrammer doesn't find STM32F103C8T6 blue pill board".
I cannot remember to have opened a "similar" topic, other than you name it to me, please. :)

This topic discussion is very close to current one.

According to the forum rules, you should have continued the discussion in that thread

I'm about to abandon Arduino IDE on the STM32 devices. My recent experience was frustrating.
I programmed the STM32F103 again with the generic_boot20_pc13.bin (using STM32Cube via UART A9/A10). Then I uploaded a blinky app using the Maple 2.0 DFU boot loader. Which worked fine.

But with the USB cable still connected and the blinky app running an error message appeared in the programming log window, saying something like the tty being lost. As a consequence a subsequent attempt to program the device failed. The tty in the /dev list of ttys was also gone. As if the DFU bootloader had been destroyed by the programming step.

Frustrating.

try this:
Start uploading code in Arduino IDE WITHOUT connect the board. When the compilation is finished and in log window appears message like "Looking for DFU device...." - only in that time connect the bluepill to the USB port. You have about 5 seconds to do this.

I helps in my case and DFU upload always goes fine.

OK. This worked once again, but I have to leave the device connected to USB to have it powered. And while it stays connected, I'm getting this as next in the log window:

Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
dfu-util: error resetting after download
dfu-util: error resetting after download

Well, programming works this way, but this kind of "interruptus" really "can't be it" :slight_smile:

I have the same.
Just ignore it

This is not a software problem, but a hardware one. On bluepill clones, the USB is incorrectly wired, so it has problems with interacting with the bus

I have moved the posts from Stm32duino environment, defines, includes? about the upload problems over to this topic. The subject matter of the other topic is the differences between the Roger Clark STM32 boards platform and the STM32duino boards platform.

IIRC, STM32f10x only has a built-in serial bootloader.
The Arduino IDE will want you to install a USB bootloader using the Serial Bootloader.
(Some boards, like a Maple, will have already done this.)

And can this be "repaired" somehow?

That's what I did before. And I'm talking about just this, the DFU boot loader.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.