Why does the FreeRTOS_CreateThread application example not allow breakpoints?

[GreenGuy]

After importing from the repo (1.3) the application example FreeRTOS_CreateThread_CM4 when loaded for debugging, the debugger fails to set breakpoints complaining that there are already too many break points set. I only set one. It looks like the application is running as I can pause the debugger and see where the code is currently executing. I can resume the application as well. Also the LEDS do not come on which is why I am trying to break point the code. Is there something special about FreeRTOS running on CM4 that precludes the use of breakpoints?

I am using:

STM32MP157-DK2

STM32CubeIDE on Linux

[Michael K]

I get "too many breakpoints set" when I have optimizations turned on and I try to break on certain parts of the code. Perhaps it doesn't like trying to break on optimized -out code? Turning optimizations off and then adding a breakpoint at the same place usually works for me.

To turn off optimizations in CubeIDE, right click the project name in the project explorer -> Properties -> C/C++ Build -> Settings -> Tool Settings, then you'll see Optimization under GCC and G++ compiler. Change to none. The compiler flags are -O0 if you do it from a makefile or command line.

Good luck!

[GreenGuy]

The build settings, Optimization was set to Debug and I changed it to None. I do not get the breakpoint warning. However, when I pause the debugger it always stops at g_pfnVectors() at 0x0 and it would appear that the code is not running but stuck at this location. Looking at the registers while paused the pc is at 0x0. I tried to delete the projects and deleted the repo and replaced it, recompiled both the OpenAMP and FreeRTOS projects. The OpenAMP works and the FreeRTOS does not ending with the same result.

[Olivier GALLIEN]

Hi @Community member​ ,

Did you get the problem also at firt debug session after hard reset ?

This trap in g_pfnVectors()  make me think of a know issue which is present when you reload a debug session without hard reset.

You can hard fault in SystemClock_Config()

If you confirm this, the solution is to add HAL_RCC_DeInit() prior to HAL_Init().

Else I wonder if FreeRTOS_CreateThread_CM4 may not have similar issue than the one detected with example OpenAMP_FreeRTOS_echo as per discussed in the post :

https://community.st.com/s/question/0D53W00000Dhrg9SAB/hal-tick-does-not-get-incremented-on-second-debug-session-after-reset-freertos

Hope it help

Olivier

[GreenGuy]

I think the answer to your first question "Did you get the problem also at firt debug session after hard reset ? " is yes.

To be clear I am having the issue the first time I invoke the debugger. The console shows the following:

Open On-Chip Debugger 0.11.0-rc2+dev-00037-g4c4dbd9 (2021-02-09-13:36)

Licensed under GNU GPL v2

For bug reports, read

   http://openocd.org/doc/doxygen/bugs.html

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : STLINK V2J37M27 (API v2) VID:PID 0483:3752

Info : Target voltage: 3.202101

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Info : clock speed 4000 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : STM32MP157CAAx.cm4: hardware has 6 breakpoints, 4 watchpoints

Info : STM32MP157CAAx.cpu0: hardware has 6 breakpoints, 4 watchpoints

Info : STM32MP157CAAx.cpu1: hardware has 6 breakpoints, 4 watchpoints

Info : STM32MP157CAAx.cm4: external reset detected

Info : starting gdb server for STM32MP157CAAx.cpu0 on 3334

Info : Listening on port 3334 for gdb connections

Info : starting gdb server for STM32MP157CAAx.cm4 on 3333

Info : Listening on port 3333 for gdb connections

Info : accepting 'gdb' connection on tcp/3333

Info : Halt timed out, wake up GDB.

Error: timed out while waiting for target halted

Error executing event gdb-attach on target STM32MP157CAAx.cm4:

Info : New GDB Connection: 1, Target STM32MP157CAAx.cm4, state: reset

Warn : GDB connection 1 on target STM32MP157CAAx.cm4 not halted

Warn : negative reply, retrying

Warn : negative reply, retrying

Info : accepting 'gdb' connection on tcp/3333

Info : Halt timed out, wake up GDB.

Error: timed out while waiting for target halted

Error executing event gdb-attach on target STM32MP157CAAx.cm4:

Info : New GDB Connection: 2, Target STM32MP157CAAx.cm4, state: reset

Warn : GDB connection 2 on target STM32MP157CAAx.cm4 not halted

Warn : negative reply, retrying

Warn : negative reply, retrying

Warn : target not halted

Info : target STM32MP157CAAx.cm4 was not halted when resume was requested

Info : The target is not running when halt was requested, stopping GDB.

Warn : target STM32MP157CAAx.cm4 is not halted (gdb fileio)

After that the debugger shows the target (CM4) running and the first thing I try to do is to pause the debugger. This brings up the code tab "g_pfnVectors() at 0x0". Nothing is viewable here as this is obviously not code space. This is the result even after adding HAL_RCC_DeInit() prior to the HAL_Init().