FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

After download, interface redirects to startup_stm32f407vgtx.s

CoArc
Associate

‎2026-04-04 4:40 AM - last edited on ‎2026-04-07 6:57 AM by

I encountered a strange problem while using STM32CubeIDE. After clicking "Debug" and then "Exit," in all subsequent actions (unless I restart the software), when I click "Download" (not "Debug"), the IDE interface redirects to another file (the line `ldr sp, =_estack /* set stack pointer */` in `startup_stm32f407vgtx.s`). While it's not a major issue, it's certainly annoying, like having sand in your shoe. I'm seeking a solution.

Labels:
4 REPLIES 4
Ghofrane GSOURI
ST Employee
In response to Pavel A.

‎2026-04-06 12:30 AM

Hello All,

@Pavel A. Thank you for your contribution.

@CoArc After checking internally this is a known issue that has been detected and escalated to dev team under internal  Ticket 162500  and it will be fixed as soon as possible.

THX

Ghofrane

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

‎2026-04-07 6:56 AM - edited ‎2026-04-08 1:34 AM

Yes - as already noted, this is a very long-running and well-known issue:

CubeIDE 2.1.0: Still opening spurious files when starting a debug session

 

PS:

With a workaround noted here.

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.
Pavel A.
Super User
In response to Andrew Neil

‎2026-04-07 11:29 PM - edited ‎2026-04-07 11:33 PM

This issue is hard to resolve IMHO because the behavior of the debugger is correct: when execution breaks, it tries to open a source file at the current point. The break in startup code during start of the session is "technical" and execution immediately resumes. But source tab/window stays open and annoys the user.

IMHO this can be "fixed" by remembering the list of open source windows (tabs) before the debugger start procedure and comparing it with state after end the start procedure. If the target state is "running": close all new windows (opened during the startup). Else leave new windows open.  This can be optimized further (for example, delay auto-opening source & disassembly windows while the debugger start procedure hasn't ended. Then cancel opening if the target state is "running". Etc... )  This approach won't affect auto-opening source when target hits normal breakpoints.

@Ghofrane GSOURI 

Top