No able to set breakpoints in CubeMx files

Sysprogs forums Forums VisualGDB No able to set breakpoints in CubeMx files

This topic contains 6 replies, has 2 voices, and was last updated by  Timo Engelmann 1 month, 1 week ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #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:

     

    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

    #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.

    #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.
    #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

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

    Timo Engelmann
    Participant

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

    #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:

    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.
    #33065

    Timo Engelmann
    Participant

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

     

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

You must be logged in to reply to this topic.