No source available for "uwTickPrio0 at 0x20000004

[sy556]

When compiling and debugging with STM32CubeIDE, it shows: uwTickprio0 at 0x200000004 has no available source and the burner is using stlink v2. What is the cause of this problem?

[Imen.D]

Hello @sy556 ,

I edited your post to translate it from Chinese to comply with the ST Community guidelines.

If possible, please share more details that can help us to understand and reproduce your issue (which device used? which Cube package and tools version, what do you expect exactly? Are you using a particular Cube example? ....)

Please follow this post on how to write your question to maximize your chances to find a solution:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/57522

[Imen.D]

I edited your post to translate it from Chinese to comply with the ST Community guidelines.

If possible, please share more details that can help us to understand and reproduce your issue (which device used? which Cube package and tools version, what do you expect exactly? Are you using a particular Cube example? ....)

Please follow this post on how to write your question to maximize your chances to find a solution:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/57522

[sy556]

What I want to ask is, why is this problem: No Source Available for "uwTickprio0 at 0x20000004, how to solve it? The compiler is STM32CubeIDE 1.12.1, and the programming device is ST-LINK.

[Tesla DeLorean]

So no details about your board the connections, or the code..

[Imen.D]

Please share more details about your hardware and software used.

But first, please make sure to use the latest release of Cube firmware package. CubeMx and CubeIDE.

[Pavel A.]

Likely the program jumped to data (corrupted stack?)

[Tesla DeLorean]

Probably because you've placed a break-point or watch-point over the variable.

It's not something that's "code" and it can't disassemble or associated it with any of the debug information or source/line details.

Is it possible to clear all watch/break-points prior to debug.

Or catch the HardFault or whatever call-tree it's trying to unpack/unwind here?

Perhaps show what exactly you're doing in main(),  or within the main.c file at line 95 ?

[Pavel A.]

The address 20000004 is on call stack. Does not look like data breakpoint.