STM32Cube Does Not Work After Formatting the Computer

[mekatronik27]

Hello,

I am working on a project using STM32CubeIDE with an STM32F103C8T6 microcontroller. After formatting my computer and reinstalling STM32CubeIDE, none of the code I write seems to run. Interestingly, I am not receiving any error messages either. I have verified that my ST-Link connection and hardware connections are correct. Below, I’ve provided detailed information about the issue. Any help would be greatly appreciated!

What I’ve Done and Checked
STM32CubeIDE Installation:

I installed the latest version of STM32CubeIDE (currently 1.13.2).

I also updated the ST-Link drivers to the latest version.

Project Build:

The project builds successfully. The console output after building is as follows:

Copy
12:41:52 **** Incremental Build of configuration Debug for project deneme ****
make -j12 all
arm-none-eabi-size deneme.elf
text data bss dec hex filename
7496 104 1904 9504 2520 deneme.elf
Finished building: default.size.stdout
12:41:52 Build Finished. 0 errors, 0 warnings. (took 197ms)
There are no errors or warnings during the build process.

Debug Configuration:

I have set up the debug configuration correctly. The .elf file is selected properly, and the ST-Link settings appear to be correct.

During the debug process, the ST-Link connection is established successfully, and the firmware is loaded onto the microcontroller. The console output is as follows:

Copy
STMicroelectronics ST-LINK GDB server. Version 7.8.0
Copyright (c) 2024, 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.17.0
-------------------------------------------------------------------

Log output file: C:\Users\binary\AppData\Local\Temp\STM32CubeProgrammer_a15220.log
ST-LINK SN : 52FF71067887525730452367
ST-LINK FW : V2J45S7
Board : --
Voltage : 1.05V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x410
Revision ID : Rev X
Device name : STM32F101/F102/F103 Medium-density
Flash size : 64 KBytes
Device type : MCU
Device CPU : Cortex-M3
BL Version : --

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

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

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

Verifying ...

Download verified successfully
Hardware Checks:

I have verified the ST-Link connections (SWDIO, SWCLK, GND, VCC) and confirmed they are correct.

I have checked the power supply to the target board and the reset pin, and there are no issues.

Summary of the Problem
My code builds successfully and is loaded onto the microcontroller via ST-Link without any issues.

However, the code does not run, and I am not receiving any error messages.

During the debug process, the microcontroller is accessible, but I am unable to determine if the code reaches the main() function.

Attempted Solutions
Reinstalled STM32CubeIDE and ST-Link drivers.

Verified the debug configuration and ensured it is set up correctly.

Checked the clock and system settings using STM32CubeMX.

Rechecked all hardware connections.

Request for Help
Has anyone else experienced this issue or have any suggestions on what might be causing it? What are the possible reasons for the code not running without any error messages? How can I further investigate the microcontroller’s registers or memory state during the debug process?

Any advice or suggestions would be greatly appreciated. Thank you in advance!

Additional Information
STM32CubeIDE Version: 1.16.1

ST-Link Version: V2J45S7

Microcontroller: STM32F103C8T6

Operating System: Windows 10

[Andrew Neil]

Welcome to the forum.

You haven't said what board, or what ST-Link you're using - please see:

How to write your question to maximize your chances to find a solution

---

@mekatronik27 wrote:

Voltage : 1.05V

---

Minimum operating voltage for stm32f103c8 is 2V:

https://www.st.com/resource/en/datasheet/cd00161566.pdf#page=38

 

[mekatronik27]

hello
I tried it on stm32f103-blupilli and stm32f429disc card, I have original stlink-v2 and tried it with it. My problem is exactly that I just installed şide and I compile the program, there are no errors but it does not work on the processor

[Andrew Neil]

---

@mekatronik27 wrote:

I tried it on stm32f103-blupilli and stm32f429disc card

---

Did they both give the same result?

An STM32F429 will also not work at 1.05V, and the stm32f429disc should be running at 3V.

Definitely something wrong here!

[Ozone]

> After formatting my computer ...

Sounds a bit dramatic. I suppose you reinstalled the OS (probably including reformatting the disk drive).

> ... and reinstalling STM32CubeIDE, none of the code I write seems to run.

Are you sure it is the same version as before ?
The version might have changed since the previous installation.

> During the debug process, the microcontroller is accessible, but I am unable to determine if the code reaches the main() function.

I don't use CubeIDE, to put that upfront.

But I suggest to change the debug settings from "run to main()" to "break at the reset vector".
After that, step through the startup and system init code.

I suspect some startup files, header or libs have changed in the meantime, and doesn't match your code.
Thus you applications get "lost" in the startup code.

[TDK]

> During the debug process, the microcontroller is accessible, but I am unable to determine if the code reaches the main() function.

Why not? What happens when you debug the application and step through it?

Sure sounds like the program is loaded and just has bugs preventing it from doing what you expect.

Voltage of 1.05 V is insufficient, suggesting issues here.