2021-03-12 12:05 PM
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
2021-03-12 12:50 PM
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!
2021-03-13 08:11 AM
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.
2021-03-15 09:55 AM
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 :
Hope it help
Olivier
2021-03-15 11:48 AM
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().