Did I "brick" my "blue pill" board(s) - ST-LINK V2 (current firmware), STM32CubeIDE (1.9.0), trivial "blink LED" project in Debug configuration.

wb0gaz · ‎2022-04-10

ST-Link V2, STM32F103C6T6A "blue pill", trivial program (version of blink LED), after pushing code to CPU (using STM32CubeIDE 1.9.0 and a current-firmware official ST-LINK V2), the board(s) appear "bricked" and don't respond to ST-LINK V2.

I am in need of a way to determine if the boards are scrap, or can be recovered from this condition.

Upon receipt (of the "blue pill" boards and the ST-LINK V2 programmer), I pre-tested the "blue pill" boards with both an official ST-Link V2 with a fresh from the package board (which comes with a blink-the-LED program). I can read out the 32768 bytes of flash memory, save to file, do a full erase, and rewrite the device with the previously saved (from the factory) 32768 byte image (which just blinks the LED on GPIOC bit 13.)

This is where the problem began:

Wrote my own version of "blink the LED" to verify I could complete the write-build-program cycle with STM32CubeIDE (using the official ST-Link V2 as the firmware in the clone ST-LINK can't be updated), and found that once my trivial program (below) was written to the blue pill board (using only STm32CubeIDE and the official ST-Link V2), the board appears "bricked", and no longer responds to the ST-LINK V2 device (either the official one or the clone.)

As it took some tries to isolate the issue which I thought was a problem with the ST-LINK device, interconnect wiring, or procedure, I've successfully "bricked" all five of my "blue pill" boards (the _last_ thing I expected was a trivial program to cause an unrecoverable state, as I've spent some months working with STM32CubeIDE and a F0 Discovery board with very good success.

I'm stuck until I can find a recovery method.

-------------------------------------------------------------------------------------------------------------------

The program (which was inserted into output from STM32CubeMX) has only this:

/* Initialize all configured peripherals */

MX_GPIO_Init();

/* USER CODE BEGIN 2 */

/* USER CODE END 2 */

/* Infinite loop */

/* USER CODE BEGIN WHILE */

while (1)

{

GPIOC->BSRR = GPIO_BSRR_BS13;

/* USER CODE END WHILE */

/* USER CODE BEGIN 3 */

}

-------------------------------------------------------------------------------------------------------------------

Below is a transcript (from STM32CubeIDE) of the build-and-program cycle with the failure appearing after I told the debugger to resume execution:

STMicroelectronics ST-LINK GDB server. Version 6.1.0

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

InitWhile : Enabled

Waiting for debugger connection...

Debugger connected

Waiting for debugger connection...

Debugger connected

Waiting for debugger connection...

-------------------------------------------------------------------

STM32CubeProgrammer v2.10.0

-------------------------------------------------------------------

Log output file: c:\users\user\appdata\local\temp\stm32cubeprogrammer_a09124.log

ST-LINK SN : 56FF66066683565235571987

ST-LINK FW : V2J39S7

Board : --

Voltage : 2.95V

SWD freq : 4000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x412

Revision ID : Rev A

Device name : STM32F101/F102/F103 Low-density

Flash size : 32 KBytes

Device type : MCU

Device CPU : Cortex-M3

BL Version : --

Memory Programming ...

Opening and parsing file: st-link_gdb_server_a09124.srec

File : st-link_gdb_server_a09124.srec

Size : 1.15 KB

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [0 1]

Download in Progress:

File download complete

Time elapsed during download operation: 00:00:00.195

Verifying ...

Download verified successfully

(AT THIS POINT, I TOLD STM32CUBEIDE DEBUGGER TO PROCEED)

Error in executing 'cont' command ...

Target is not responding, retrying...

Failed to read registers from target

Target is not responding, retrying...

-------------------------------------------------------------------------------------------------------------------

Restarted STM32CubeIDE, told it to run the program (in Debug mode):

Error in final launch sequence:

Failed to start GDB server

Error in initializing ST-LINK device.

Reason: (4) No device found on target.

-------------------------------------------------------------------------------------------------------------------

Now that the target blue pill device appears "bricked", I switched to STM32CubeProgrammer and am unable to go through the target connect sequence (tried with normal software reset option as well as hardware reset option, pressing the RESET button on the board in attempt to get a connection to form, however, upon releasing the RESET button, (DEV_TARGET_HELD_UNDER_RESET) appears.

11:22:26 : ST-LINK SN : 56FF66066683565235571987

11:22:26 : ST-LINK FW : V2J39S7

11:22:26 : Board : --

11:22:26 : Voltage : 3.14V

11:22:26 : Error: No STM32 target found!

11:22:33 : ST-LINK SN : 56FF66066683565235571987

11:22:33 : ST-LINK FW : V2J39S7

11:22:33 : Board : --

11:22:33 : Voltage : 3.18V

11:22:34 : SWD freq : 4000 KHz

11:22:34 : Connect mode: Normal

11:22:34 : Reset mode : Hardware reset

11:22:34 : Device ID : 0x412

11:22:34 : Revision ID : Rev A

11:22:34 : ST-LINK SN : 56FF66066683565235571987

11:22:34 : ST-LINK FW : V2J39S7

11:22:34 : Board : --

11:22:34 : Voltage : 3.19V

11:22:34 : Error: No STM32 target found!

11:22:39 : ST-LINK SN : 56FF66066683565235571987

11:22:39 : ST-LINK FW : V2J39S7

11:22:39 : Board : --

11:22:39 : Voltage : 3.16V

11:22:41 : Error: ST-LINK error (DEV_TARGET_HELD_UNDER_RESET)

wb0gaz · ‎2022-04-10

Found the solution (had I searched for "bricked blue pill" I'd have saved myself some grief!) ---

https://community.st.com/s/question/0D50X0000C6bFEZSQ2/stm32f103c8t6-bluepill-bricked-after-debugging-with-stm32cubeide

jblai.1 (Community Member)

Edited April 14, 2020 at 2:21 AM

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.

Selected as Best

So, I've now got a stack of these things to fix back and learn about switching on Serial Wire Debugging!)

View solution in original post

wb0gaz · ‎2022-04-10

Found the solution (had I searched for "bricked blue pill" I'd have saved myself some grief!) ---

https://community.st.com/s/question/0D50X0000C6bFEZSQ2/stm32f103c8t6-bluepill-bricked-after-debugging-with-stm32cubeide

jblai.1 (Community Member)

Edited April 14, 2020 at 2:21 AM

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.

Selected as Best

So, I've now got a stack of these things to fix back and learn about switching on Serial Wire Debugging!)

wb0gaz · ‎2022-04-16

As a follow-up --- the original failed board failed again (stuck without visibility to STLINK device, even though the requisite SYS> parameter was set properly by STM32CubeMX.) The problem was found among the parts soldered (barely?) to the back side of the board - R3 (100K 0603) had popped off, and this part is in the BOOT0 jumper path (I suspect flexing in the board while moving the jumpers on the top side was the culprit.) Replaced that part and then was able to use jlbai.1 method (from April 2020) to recover it. This obviously is just an electrical/mechanical problem, but there are so many of these boards in circulation I wanted to add this note as a possibility if anyone has "incorrigible" sort of problem like this.