2025-03-04 4:14 AM
For some reason my STM32CubeIDE debug mode is not working for my STM32F469I-DISCO board. Whenever I run the debugger, the screen on the STM32F469I-DISCO does not initialize (stays black), even when I press the Resume button (play/pause icon). If I press the pause icon, the debugger session seems to crash/exit. It ignores breakpoints. It's as if the STM32F469I-DISCO is in its own little world, wholly unconcerned with whatever I do. I have attached a video demonstrating the issue.
2025-03-04 4:28 AM
I would recommend to disable the "hidden part" of the debugger.
I'm not a Cube user, but I'm quite sure it has a setting "run to main()" enabled by default.
Disable the setting, and put a breakpoint in the startup code, as early as possible.
I suspect some init code fails, either RAM init, clock setup, or (as probably in your case) setup of the ext. memory interface.
2025-03-04 5:05 AM
@Ozone wrote:I'm not a Cube user, but I'm quite sure it has a setting "run to main()" enabled by default
Indeed it does:
In the 'Debug Configuration' settings
2025-03-05 5:18 AM
2025-03-05 5:52 AM
I would set the breakpoint before the "b LoopCopyDataInit".
Or on the first instruction of this loop.
Which is the place where values of initialized variables are copied in (from Flash to RAM).
Those variables usually end up in a separate linker section.
Perhaps you changed something in you project, and something got mixed up which results in RAM beyond this section gets overwritten.
Which would require a cross-check with the map file.
I had similiar issues when I tried get older SPL examples running with startup code and CMSIS versions that differed from the original one. I ended up removing all the "newer" CMSIS and device headers from the project, and copied the original old variants in.
In my case, the toolchain / IDE was different as well. (Segger ES versus Crossworks or Atollic).
But I wouldn't put it beyond Cube to mess up existing projects when updating e.g. the CMSIS version.