Skip to main content
Graduate II
October 5, 2025
Solved

Nucleo U575ZI-Q debug problem

  • October 5, 2025
  • 1 reply
  • 345 views

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. 

    This topic has been closed for replies.
    Best answer by AScha.3

    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:

    AScha3_0-1759687688661.png

    (on F103 in pic)

    1 reply

    Super User
    October 5, 2025
    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.

    SkfirAuthor
    Graduate II
    October 5, 2025

    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.3Answer
    Super User
    October 5, 2025

    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:

    AScha3_0-1759687688661.png

    (on F103 in pic)