cancel
Showing results for 
Search instead for 
Did you mean: 

Bluepill: ST LINK connects but flashes temporary .srec file instead of project .elf

Safana_M_E
Associate

I’m facing an issue while debugging my STM32F103C8T6 (Bluepill) board using ST-LINK V2 and STM32CubeIDE. The connection and flashing both seem successful, but the program doesn’t actually start running on the board.

When I check the console log, I noticed that STM32CubeIDE isn’t flashing my project’s .elf file  it’s flashing a temporary .srec file created by the GDB server instead.

I have checked the run and debug configuration and verified. path is pointing to the correct location where .elf file is created.

Here’s the relevant log output:

 

STMicroelectronics ST-LINK GDB server. Version 7.11.0
Copyright (c) 2025, STMicroelectronics. All rights reserved.

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.20.0
-------------------------------------------------------------------

Log output file: C:\Users\safan\AppData\Local\Temp\STM32CubeProgrammer_a38588.log
ST-LINK SN : B55B5A1A0000000082E4F501
ST-LINK FW : V2J46S7
Board : --
Voltage : 3.22V
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 : --

Opening and parsing file: ST-LINK_GDB_server_a38588.srec

Memory Programming ...
File : ST-LINK_GDB_server_a38588.srec
Size : 4.52 KB
Address : 0x08000000

Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4]
Download in Progress:

File download complete
Time elapsed during download operation: 00:00:00.402

Verifying...

Time elapsed during verifying operation: 00:00:00.029

Download verified successfully

 

6 REPLIES 6
Peter BENSCH
ST Employee

Welcome @Safana_M_E, to the community!

Please show a photo of your ST-LINK/V2, front and back.

In addition, you should ensure that the STM32F103C8T6 on your Bluepill is not one of the many clones or illegal counterfeits that are not supported by the tools of STMicroelectronics (extremely high probability). Here in the community, there are many requests from users who want to save a few cents, find such counterfeits (with faked markings) or clones, and then wonder why they do not work as desired - same for Bluepills, which for years now have only very rarely been equipped with original devices, see e.g. this discussion.

Regards
/Peter

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Andrew Neil
Super User

Welcome to the forum.

Please see  How to write your question to maximize your chances to find a solution for best results.

 

As @Peter BENSCH said, BluePill is not an ST Product, and likely does not have a genuine STM32.

Also, are you using a genuine ST-Link? See: How to recognize a genuine ST-LINK/V2 versus a cloned one.

 

What CubeIDE version are you using, and on what Host platform?

Have you reconfigured it to use a non-standard GDB ?

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.

Yes, I have checked and  I am using a St link Clone. My Cubeide version is 1.16.1. I haven't reconfigured it to use a non-standard GDB. Is their anyway I can make it work? I have worked on bluepill before, and was able to debug problem faced with connection then.

You still didn't say what Host platform you're running on.

1.16.1 is quite old ...

 


@Safana_M_E wrote:

I have worked on bluepill before, and was able to debug problem faced with connection then.


Recently? Using the same Bluepill board? And the sane CubeIDE?

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.

No It was long ago. I was using another board and another st-link(which also was a clone). the cubeide was same version but on different system. 

 

You still haven't said what Host system you're using!

 

I just checked with a genuine ST Nucleo board:

ST-LINK SN : 0670FF3732584B3043190638
ST-LINK FW : V2J46M31
Board : NUCLEO-F030R8
Voltage : 3.25V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x440
Revision ID : Rev 2.0
Device name : STM32F05x/F030x8
Flash size : 64 KBytes
Device type : MCU
Device CPU : Cortex-M0
BL Version : 0x21

Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a26192.srec
File : ST-LINK_GDB_server_a26192.srec
Size : 25.17 KB
Address : 0x08000000

 

So this is normal.

 

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.