cancel
Showing results for 
Search instead for 
Did you mean: 

Debug Mode not Working STM32F469I-DISCO in STM32CubeIDE

Kneepatch
Senior

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.

-Kneepatch
4 REPLIES 4
Ozone
Lead III

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.


@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:

AndrewNeil_0-1741093512713.png

In the 'Debug Configuration' settings

Kneepatch
Senior

Tried what you suggested. Unchecked the Set breakpoint at: main option. Set a breakpoint here:

Kneepatch_0-1741180108959.png

Still get bizarre behavior (attached another video).

Here are my settings in STM32CubeIDE:

Kneepatch_2-1741180211669.png

Kneepatch_3-1741180218210.png

Kneepatch_1-1741180194691.png

-Kneepatch

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.