Zephyr with STM32H735g_disco board crashes when executing the z_msleep function

[MCons.2]

Project: samples/basic/blinky

board: stm32h735g_disco

I am using the latest Zephyr 4.1

If have a simple project `sample/basic/blinky`. Using the west command to compile the project, flash the board, debug the board with OpenOCD protocol.

Everytime I used the debugger (dbg), I am able to step by step the project until I reach the k_msSeep() function.

A friend of mine help me to debug it and we were able find that the system breaks as indicated in the picture below.

If I don't use the debugger DBG, then the software does not crash... It just work.

 

[Pavel A.]

IIRC gdb (or certain "target monitors") have problems with single-stepping thru some ARM assembly inlines. Unless you want to debug the debugger - avoid single stepping thru these things. 

 

[MCons.2]

@Pavel A. It doesn't need to be single stepping. Just need to be in debug mode. The problem occurs with the `west debug` command or with the STM32CubeIDE. If I just flash it, it is working with no issue. Not very practical to design a new application.

[Joe WILLIAMS]

Hi MCons.2

This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.

Regards

Joe

STMicro Support

[MCons.2]

Here is the answer from ST Support.

 

Please ask the customer to add the following line to the prj.conf:
CONFIG_STM32_ENABLE_DEBUG_SLEEP_STOP

west build -p always -b stm32h735g_disco samples\basic\blinky
west flash
west debug

According to C:\zephyrproject\zephyr\soc\st\stm32\Kconfig:
config STM32_ENABLE_DEBUG_SLEEP_STOP
 bool "Allow debugger attach in stop/sleep Mode"
 help
 Some STM32 parts disable the DBGMCU in sleep/stop modes because
 of power consumption. As a side-effects this prevents
 debuggers from attaching w/o resetting the target. This
 effectivly destroys the use-case of `west attach`. Also
 SEGGER RTT and similar technologies need this.