Strange behavior while debugging, "step over" jumps not to next row

[TheImmortal]

I trying to debug to find what line in initialization function throw hard fault and cant understand why "jump over" dont work like expected, in some moments jumps not to next row in code, then goes back...

After running normally must start at  SCB_EnableICache() line, but starts from main:

Then step by step must goes in that way:

But goes/jumps in this way:

SCB_EnableICache();
SCB_EnableDCache();
MPU_Config();
MX_GPIO_Init();
SystemClock_Config();

And throws hard fault error inside SystemClock_Config function at HAL_Delay(HSE.....

I am not sure if hard fault is fired because there is misconfig in cubeMX (I think not), or there because in some way is missed HAL_Init and other initializations, code cleaning, restarting and other things does not change anything, I have posted about some other problems earlier with initializations and bugs, but now I stuck there and cant work with code at all, cubeMX, cudeIDE, mcu package and everything else is updated to last available versions !

Main problem is what these bugs and problems will fail all the huge project which have investors, our team will not fit in time !!

[KnarfB]

This is usually due to compiler optimization. Try setting -O0. Depending on your IDE you may find a fault analyzer which helps decoding the reason for the fault.

hth

KnarfB

[TheImmortal]

This helped to solve "jumping" problem, thanks.

[TDK]

What board are you working with? Is SMPS a valid power configuration?

Not using HSE, so there's no reason to delay until it's valid. Code isn't entirely MX-generated, appears to be out of sync.

[TheImmortal]

There is custom PCB, code is CubeMX generated, I just deleted comments before posting there for easier readability for help...

There is used internal SMPS and working well, voltages is correct, and output is checked with oscilloscope.

Problem occurred after enabled NETXDUO, THREADX, USBX middlewares or additional USB settings, I enabled them all and then got stuck with hard fault in HSE initialization on HAL_Delay, before with a lot of enabled peripherals and working code I do not have problems there, now I switched to use HSI and problem is gone, maybe there is problem with HAL_Delay because NETXDUO and THREADX use RTOS and there can't be used HAL_Delay ? But then means what CubeMX generate wrong code at all ?

For this moment I dont have time to search what cause this problem and will use HSI, but if you can point what to check and where to search for problems it can help there... Thanks.

[Tesla DeLorean]

With optimization there can be non-linear code relationships, ie not 1:1 relationship in code/flow of C vs Assembler.

Also there will be granularity in debug data relating code lines, to opcode addresses, perhaps a one-to-many.

You're talking about the STM32N chips

The STM32F74x/5x parts used a Cortex-M7 core which had some single-step issues

https://community.st.com/t5/stm32-mcus-products/stm32f746-cortex-m7-silicon-bug-singlestep-lands-in-interrupt/td-p/357481/page/2

[Pavel A.]

These SCB_cache functions are complicated inlines that [often] confuse the debugger.

Avoid single stepping thru them. Set a breakpoint on some line after them (MPU_Config) and run full speed to the breakpoint.  Optimization -O0 is possible but IMHO too radical.

If you suspect that the displayed source does not match the actual code, use the disassembly view or 'stepping by instruction' mode.

 

[Andrew Neil]

---

@Pavel A. wrote:

complicated inlines that [often] confuse the debugger.

---

Indeed - caught me out only yesterday:

https://community.st.com/t5/stm32cubeide-mcus/no-code-generated-for-inline-function-call/m-p/817359

(and my inlines weren't even complicated!)