Topic: No able to set breakpoints in CubeMx files

Tagged: debug breakpoint cubemx

This topic has 6 replies, 2 voices, and was last updated 2 years, 3 months ago by Timo Engelmann.

Viewing 7 posts - 1 through 7 (of 7 total)

Author

Posts
August 16, 2022 at 11:43 #33031
Timo Engelmann
Participant
Dear Sysprogs Support,

I have a CMake Project with STM32 and STM32CubeMx Support.
Everything is working fine. I can debug my own *.cpp files.
But each breakpoint in the generated *.c files results in a “Cannot resolve breakpoint location…” (empty red dot).
The GDB Session Windows report following:
```
Program
received signal SIGTRAP, Trace/breakpoint trap.
0x080048b8 in prvIdleTask ()
*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x080048b8",func="prvIdleTask",args=[],arch="armv7e-m"},thread-id="1",stopped-threads="all"
-break-insert -f C:/_Dev/Projects/AMPS/Repos/amps_ctrl/Firmware_AMPSv2_Controller/Firmware_VisualGDB/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/cmsis_os2.c:2149
&"No source file named C:/_Dev/Projects/AMPS/Repos/amps_ctrl/Firmware_AMPSv2_Controller/Firmware_VisualGDB/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/cmsis_os2.c.\n"
^done,bkpt={number="7",type="breakpoint",disp="keep",enabled="y",addr="",pending="C:/_Dev/Projects/AMPS/Repos/amps_ctrl/Firmware_AMPSv2_Controller/Firmware_VisualGDB/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/cmsis_os2.c:2149",times="0",original-location="C:/_Dev/Projects/AMPS/Repos/amps_ctrl/Firmware_AMPSv2_Controller/Firmware_VisualGDB/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/cmsis_os2.c:2149"}
-exec-continue
^running
*running,thread-id="all"
```
But the files are existing and if I build in a syntax error the compiler will find this too.
Unfortunately I don’t have found some hints in the existing forum entries.
Is there a additional setting of “Debug Information Format” for C-Files?
Currently the content of this option is: Optimized for GDB (-ggdb)

Best regards,
Timo
August 16, 2022 at 12:11 #33032

support
Keymaster

Hi,

Most likely, you have inadvertently overridden the CFLAGS for some files. You can use the techniques shown in this tutorial to verify whether the object files contain symbols.

If the symbols are missing, please try adding an #error directive to one of the affected files. If you are using Ninja, it will show the exact command line used to build that file. If the -ggdb option is missing, please double-check your CMake scripts.

August 19, 2022 at 01:32 #33050

Timo Engelmann
Participant

Hi,

now I have checked the issue with a new empty CubeMx project.
Following results:

1. Setup
Creation of a fresh CubeMx CMake project.
Build was successful and breakpoint in system_stm32g4xx.c and in main.c was stopping the execution -> perfect!
Hint: the field “Project Property Pages / C/C++ / General / Debug Information Format” was empty and was not changed.
2. main.cpp
Excluding the original main.c file from build and added a copy of this file in an other folder and renamed it to main.cpp
Build was successful and breakpoint in system_stm32g4xx.c and in main.cpp was stopping the execution -> perfect!
Hint: the field “Project Property Pages / C/C++ / General / Debug Information Format” was still empty.
See attached image: 01.jpg

3. Change Configuration name
The name of the “Debug” configuration in “Manage Platforms and Configurations” dialog changed to “Renamed”.
See attached image: 03.jpg

4. Build again and start Debugging
Build was successful but now both breakpoints are not available.
See attached image: 05.jpg

5. Try to use the “Diagnose…” button
No success in “Reload Symbols” at the Diagnose dialog.
See attached image: 07.jpg

Please see the next post, because only 4 images are possible here….

Attachments:
You must be logged in to view attached files.

August 19, 2022 at 01:53 #33055
Timo Engelmann
Participant
6. Add “Optimized for GDB (-ggdb)” option
See attached image 08.jpg

7. Build again and start Debugging
Build was successful and now only the breakpoint in “main.cpp” (my own file) is available. The Breakpoint in “system_stm32g4xx.c” is still not available.
See attached image: 09.jpg

8. #error “Test” added in “system_stm32g4xx.c”
Output:

Run "C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe " in directory "C:\_Dev\Projects\eti2si\Repos\EmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj/build/VisualGDB/Renamed" on local computer
C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe
[1/3] Building C object CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj
FAILED: CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj
c:\sysgcc\arm-eabi\bin\arm-none-eabi-gcc.exe -DSTM32G474xx -DUSE_HAL_DRIVER -I../../../Core/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc/Legacy -I../../../Drivers/CMSIS/Device/ST/STM32G4xx/Include -I../../../Drivers/CMSIS/Include -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mhard-float -MD -MT CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj -MF CMakeFiles\BSP.dir\Core\Src\system_stm32g4xx.c.obj.d -o CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj -c ../../../Core/Src/system_stm32g4xx.c
../../../Core/Src/system_stm32g4xx.c: In function 'SystemInit':
../../../Core/Src/system_stm32g4xx.c:181:2: error: #error "Test"
181 | #error "Test"
| ^~~~~
ninja: build stopped: subcommand failed.

No -ggdb option is set.

9. #error “Test” added in my “main.cpp”
Output:

Run "C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe " in directory "C:\_Dev\Projects\eti2si\Repos\EmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj/build/VisualGDB/Renamed" on local computer
C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe
[1/4] Building CXX object CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj
FAILED: CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj
c:\sysgcc\arm-eabi\bin\arm-none-eabi-g++.exe -DSTM32G474xx -DUSE_HAL_DRIVER -I../../../Core/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc/Legacy -I../../../Drivers/CMSIS/Device/ST/STM32G4xx/Include -I../../../Drivers/CMSIS/Include -ggdb -fno-exceptions -fno-rtti -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mhard-float -MD -MT CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj -MF CMakeFiles\VisualGdbEmptyCubeMxPrj.dir\main.cpp.obj.d -o CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj -c ../../../main.cpp
../../../main.cpp:93:2: error: #error "Test"
93 | #error "Test"
| ^~~~~
[2/4] Building C object CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj
ninja: build stopped: subcommand failed.

Here the -ggdb option is set.

10. Renamed the configuration from “Renamed” back to “Debug”
Build was successful and both breakpoints are working. (Hint: the #error lines are removed before build.)

After adding both #error “Test” lines again following output:

Run "C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe " in directory "C:\_Dev\Projects\eti2si\Repos\EmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj/build/VisualGDB/Debug" on local computer
C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe
[1/4] Building C object CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj
FAILED: CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj
c:\sysgcc\arm-eabi\bin\arm-none-eabi-gcc.exe -DSTM32G474xx -DUSE_HAL_DRIVER -I../../../Core/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc/Legacy -I../../../Drivers/CMSIS/Device/ST/STM32G4xx/Include -I../../../Drivers/CMSIS/Include -g3 -O0 -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mhard-float -MD -MT CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj -MF CMakeFiles\BSP.dir\Core\Src\system_stm32g4xx.c.obj.d -o CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj -c ../../../Core/Src/system_stm32g4xx.c
../../../Core/Src/system_stm32g4xx.c: In function 'SystemInit':
../../../Core/Src/system_stm32g4xx.c:181:2: error: #error " Test"
181 | #error " Test"
| ^~~~~
[2/4] Building CXX object CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj
FAILED: CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj
c:\sysgcc\arm-eabi\bin\arm-none-eabi-g++.exe -DSTM32G474xx -DUSE_HAL_DRIVER -I../../../Core/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc/Legacy -I../../../Drivers/CMSIS/Device/ST/STM32G4xx/Include -I../../../Drivers/CMSIS/Include -g3 -O0 -ggdb -fno-exceptions -fno-rtti -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mhard-float -MD -MT CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj -MF CMakeFiles\VisualGdbEmptyCubeMxPrj.dir\main.cpp.obj.d -o CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj -c ../../../main.cpp
../../../main.cpp:93:2: error: #error " Test"
93 | #error " Test"
| ^~~~~
ninja: build stopped: subcommand failed.

Result: the -ggdb is only used for the main.cpp.

11. Removing the “Optimized for GDB (-ggdb)” option
Build was successful and both breakpoints are working. (Hint: the #error lines are removed before build.)

After adding both #error “Test” lines again following output:

Run "C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe " in directory "C:\_Dev\Projects\eti2si\Repos\EmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj\VisualGdbEmptyCubeMxPrj/build/VisualGDB/Debug" on local computer
C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe
[1/4] Building C object CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj
FAILED: CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj
c:\sysgcc\arm-eabi\bin\arm-none-eabi-gcc.exe -DSTM32G474xx -DUSE_HAL_DRIVER -I../../../Core/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc/Legacy -I../../../Drivers/CMSIS/Device/ST/STM32G4xx/Include -I../../../Drivers/CMSIS/Include -g3 -O0 -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mhard-float -MD -MT CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj -MF CMakeFiles\BSP.dir\Core\Src\system_stm32g4xx.c.obj.d -o CMakeFiles/BSP.dir/Core/Src/system_stm32g4xx.c.obj -c ../../../Core/Src/system_stm32g4xx.c
../../../Core/Src/system_stm32g4xx.c: In function 'SystemInit':
../../../Core/Src/system_stm32g4xx.c:181:2: error: #error " Test"
181 | #error " Test"
| ^~~~~
[2/4] Building CXX object CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj
FAILED: CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj
c:\sysgcc\arm-eabi\bin\arm-none-eabi-g++.exe -DSTM32G474xx -DUSE_HAL_DRIVER -I../../../Core/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc -I../../../Drivers/STM32G4xx_HAL_Driver/Inc/Legacy -I../../../Drivers/CMSIS/Device/ST/STM32G4xx/Include -I../../../Drivers/CMSIS/Include -g3 -O0 -fno-exceptions -fno-rtti -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mhard-float -MD -MT CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj -MF CMakeFiles\VisualGdbEmptyCubeMxPrj.dir\main.cpp.obj.d -o CMakeFiles/VisualGdbEmptyCubeMxPrj.dir/main.cpp.obj -c ../../../main.cpp
../../../main.cpp:93:2: error: #error " Test"
93 | #error " Test"
| ^~~~~
ninja: build stopped: subcommand failed.

Now the option -gddb is not used but all breakpoints are working.

Conclusion:
It seems that there are two different issues active:
1. The name of the configuration is used to change debugging parameter
2. The option -gddb is not used for the CubeMx Files or for plain c files.

I hope you can follow my description above and find a solution to give the configurations names without changing the settings.

Best regards Timo
- This reply was modified 2 years, 3 months ago by Timo Engelmann.
Attachments:
You must be logged in to view attached files.
August 19, 2022 at 04:07 #33059

Timo Engelmann
Participant

One additional info:
It seems that it is sufficient if the string “Debug” is included in the configuration name.

August 19, 2022 at 09:21 #33063
support
Keymaster
Thanks for the detailed screenshots, we would have never guessed what you were trying to do otherwise.

Below is the explanation of what is going on:
1. Renaming the configuration from Debug to Renamed and not changing the build type changes the CMake command line issued by VisualGDB from -DCMAKE_BUILD_TYPE=DEBUG to -DCMAKE_BUILD_TYPE=RENAMED.
2. CMake does not know the RENAMED build type, so it never passes the debug-specific arguments to GCC.
3. In step 6 (08.jpg) you override the debug information format for the executable only (not the STM32CubeMX libraries). This happens because you do it via the properties for the executable (node with the console icon in Solution Explorer).
The workaround is extremely easy though: simply set the CMake build type to DEBUG for the renamed configuration, and it will automatically get the correct flags:

You can also proceed with your own custom build type (in case you need it for any reason) by adding the following lines to CMakeLists.txt:
```
set(CMAKE_C_FLAGS_RENAMED ${CMAKE_C_FLAGS_DEBUG})
set(CMAKE_CXX_FLAGS_RENAMED ${CMAKE_CXX_FLAGS_DEBUG})
```
That said, we would advise using the classical CMake build types (Debug/Release/RelWithDebInfo) and manually passing additional definitions to CMake if you need different configurations to produce different outputs.

Attachments:
You must be logged in to view attached files.
August 19, 2022 at 09:38 #33065

Timo Engelmann
Participant

Perfect!
Thanks for this good explanation!
I should learn a little more about CMake 🙂
Author

Posts

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Attachments:

Attachments:

Attachments: