cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103C8T6 (BluePill) bricked after debugging with STM32CUBEIDE

ZTodo.1
Associate II

I have recently bought 3 BluePills (STM32F103C8T6) and 1 ST-LINK V2 from ebay. I have been succesfully testing some old codes with Coocox Studio, but I decided to try out STM32CUBEIDE. Once I set up STM32CUBEIDE and built the program, I noticed that there's debugging option so I went with it. Unfortunately I wasn't able to debug the program - the chip would not be flashed successfully because the device would not be found or disconnected. I was/am receiving these messages

Error in final launch sequence:

Failed to execute MI command:

-exec-run

Error message from debugger back end:

Error creating process C:/Users/zdrav/Google Drive/STM32CUBEIDE/PWM/Debug/PWM.elf, (error 193).

Failed to execute MI command:

-exec-run

Error message from debugger back end:

Error creating process C:/Users/zdrav/Google Drive/STM32CUBEIDE/PWM/Debug/PWM.elf, (error 193).

Error creating process C:/Users/zdrav/Google Drive/STM32CUBEIDE/PWM/Debug/PWM.elf, (error 193).

I also can't run the program

Error starting process.

Cannot run program "C:\Users\zdrav\Google Drive\STM32CUBEIDE\PWM\Debug\PWM.elf": Launching failed

Cannot run program "C:\Users\zdrav\Google Drive\STM32CUBEIDE\PWM\Debug\PWM.elf": Launching failed

Cannot run program "C:\Users\zdrav\Google Drive\STM32CUBEIDE\PWM\Debug\PWM.elf": Launching failed

Now since I couldn't do anything from STM32CUBEIDE I decided to see if Coocox works. I wasn't able to burn the program to the Bluepill which previously was 'burned' with STM32CUBEIDE. I am receiving the following messages

Error: Connect failed, check config and cable connection

I was able to burn other Bluepills with Coocox which were not burned with STM32CUBEIDE, by just switching the Bluepill, but I thought I would want to give all 3 bluepills a burn with STM32CUBEIDE, now none of the chips can be burned.

What can be done now ?

1 ACCEPTED SOLUTION

Accepted Solutions
jblai.1
Associate II

I did something similar - made my Blue Pill boards unresponsive after flashing and debugging with STM32CubeIDE. The reason was that in my project I had not switched on Serial Wire debugging in STM32CubeIDE under the System Core/SYS parameters. The solution was to move the 2 jumpers on the Blue Pill board from their default position (both near the USB connector) to the opposite position (both nearer the processor chip), press the reset button, and re-flash. Then move the jumpers back to their original position.

View solution in original post

5 REPLIES 5
Bob S
Principal

Use the STLink GUI or STM32CubeProgrammer software and see if they can connect to the board. I'm not very familiar with the blue pill boards other than they are pretty bare bones. A wild guess, but maybe, somehow, when programming from CubeIDE it set RDP mode to 1, which prevents debugging. Anyway, try the stand-alone programmer software and see what it shows. If RDP *IS* set to 1, you can then reset it to zero which will also erase the entire FLASH contents.

I have installed STM32CubeProgrammer and I can't connect the Bluepill to the stlink2, but I successfully upgraded the firmware

jblai.1
Associate II

I did something similar - made my Blue Pill boards unresponsive after flashing and debugging with STM32CubeIDE. The reason was that in my project I had not switched on Serial Wire debugging in STM32CubeIDE under the System Core/SYS parameters. The solution was to move the 2 jumpers on the Blue Pill board from their default position (both near the USB connector) to the opposite position (both nearer the processor chip), press the reset button, and re-flash. Then move the jumpers back to their original position.

I followed these steps and now it works like normal.

AJoha.6
Associate

I just did the same mistake as OP, resulting in bricking 4x stm32f103c8t6 / blue pills before i noticed. I just wanted to document and share my solution in case it ever happens again.

Hardware:

  • stm32f103c8t6 (1x "real" and 3x "fake")
    • Both jumper on BOOT-mode (both near usb)
    • USB-power
  • 1x ST-LINK V2-1 (From nucleon-l476rg) with updated FW (Latest ver. as of 2022-05-09)

Software:

  • STM32cube programmer (Latest ver. as of 2022-05-09)
    • Port: SWD
    • Freq.: 4000
    • Mode: Under Reset
    • Acces. port: 0
    • Reset mode: Hardware ..
    • Speed: reliable
    • Shared: Disabled
  • Debian 20.04 (Linux)

Problem:

  • The blue pills got bricked after using STM32cubeIDEs programming interface (Run debug/Run Application). It worked when i was using CLI for st-link (e.g. st-link --probe) before downloading cubeIDE.
  • Can reach the blue pill when holding down reset, but not when releasing.

Error codes:

  • Error in initializing ST-LINK device.

Reason: No device found on target.

  • Failed to enter SWD mode
  • Failed to connect to target
  • ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again

Solution:

  • Set jumper from NRST (marked "R" on board) to NRST on ST-LINK V2
  • Connect with STM32CUBE programmer (set as in "Hardware")
  • Press eraser button (Erase all) -> OK
  • Confirmed by: st-link --probe -> st-flash write .... (Solution OK)

I hope this helps!