Nucleo U575ZI-Q debug problem

[Skfir]

Hello everybody! I recently started experiencing weird, unstable behavior during debug on my Nucleo u575zi-q board. So, I don't use HAL, or any graphic programming, or any API, doing everything in pure C from scratch. The IDE I use is, of course, the STM32 CUBE. It is the Mac version, 1.19.0. When my project was simple, everything was okay; the ST-LINK debug worked great. At some point, though, the debug became unstable. Sometimes the debug freezes, but more often it somehow ends up doing more strange things. For example, I have an RTC module in my project, and in the code, I wait for the RSF flag:

while(!(RTC->ICSR & RTC_ICSR_RSF)){};

When I download the code to my NUCLEO board and run it, everything is fine. But when I debug the same code, press the "run" button, the debug gets frozen on waiting for this flag to be set, and it seems that the flag, for some reason, never sets! So the debug doesn't work. I turn off the debug session, and the code runs well again! Sometimes the board may totally freeze during the debug, and sometimes the debugger complains that it cannot read all the registers. Usually, what I do I "clean the project", turn off the STM32 CUBE, disconnect the board, connect it back, start the CUBE again, and then the debug will work, but just once. As soon as I end the debug session and restart it, nothing works again. Guys, please help! Does anybody have any clue what that may be? I have already tried to re-flash the ST-LINK, but alas, to no avail. 

[AScha.3]

Spoiler

Hi,

Just make a simple program using Cube and HAL, then try debug on it;

And don't forget to set the debug mode in Cube, to have the used pins fixed to be for debug.

So you see, is it a problem with the CPU and debug, or something you do wrong in your program.

[Skfir]

Simple programs run fine. And I cannot fathom even potentially what I could do to make the debug buggy. Perhaps there are some pins on the MCU that are used for the ST-Link debug, and I perhaps messed up with their configuration?.. If anybody knows, if there are such "special" ST-Link debug pins, which I shouldn't use?

[AScha.3 · Accepted solution]

Sure, if you use the pins for anything , debug is gone.

Its first on a setup for the cpu pins, to define the pins for debug - if you want debug at all.

No configuration needed, they work at reset already; just do not touch them. :)

Read and  see in ds, pin descriptions , pin definitions at start/reset, 

or just see in Cube -> pinout view, set debug or trace and you see the needed pins:

(on F103 in pic)

[Skfir]

Bingo!!! That was it! Shame on my old bald gray-haired mug! OMG! I used one of those pins as SPI CLK. God *** it. This thread is worth remembering, as I have struggled for about a month, unable to understand what the hell was going on. And you know what, if the debugger just stopped working altogether, the whole issue would be easy to trace, but the point is, it still worked, just not always, and not everything. So basically speaking, it became moody, instead of dead, and that is what just drove me nuts, because the behavior was inconsistent. 

So, ladies and gentlemen, if suddenly your ST-Link debugger runs weird, check if you use the dedicated ST-Link debug pins for something else in your project! 

What a relief, thank you!! I have already almost pulled out all of the hairs on my arse in futile attempts to find the reason and trace the logic of why things ran crazy during the debug.

Many thanks once again.