#CLION DEBUGGER NOT WORKING CODE#
#CLION DEBUGGER NOT WORKING WINDOWS#

Gdb from cmd prompt inside the build folderĪnd the same result I get when I use following CLI GDB Server in another command prompt window as by executing following command while the Jlink GDB server GUI is running in the background with configuration like the image belowĪnd the gdb communication works fine as below While using the command line I can easily debug with no issues (note I go to the build folder and run the arm-none-eabi-gdb from there) and in the image below one can see everything works fine

#CLION DEBUGGER NOT WORKING WINDOWS#

Note: the arm-none-eabi-gdb and JLinkGDBServerCL both are in the Windows PATH environment My CMakeLists.txt file (last part is UPLOAD Target) is depicted below To be more detailed I am using following configuration (I am also using J-Link hardware as my debugger connected via SWD on a STM32F103RBT6 board). The problem that I have is with debugging using the arm-none-eabi-gdb debugger in the Embedded GDB Server configuration in the CLion configuration, simply it does not work properly when I execute the debug from CLion. The compilation is complete and following files are created under the cmake-build-debug folder (Note: I have used -g -Og for compiling with -DDEBUG flag). I am using J-Link GDB server and arm-none-eabi-gdb as debugger in Windows10

#CLION DEBUGGER NOT WORKING CODE#

If it works, and your code doesn't work with GDB, then you can easily look for difference and find the issue.I have a problem with making the gdb-debug to work in CLION I'd advice you to build and flash some simple example from libopencm3-examples (like this one), and try to debug it with GDB. Everything works as expected.Īlso it should be mentioned that I'm using libopencm3 in my firmware, so it also might have some influence over success of operation. /cm3/vector.c:68Ħ8 for (src = &_data_loadaddr, dest = &_data Īnd then use usual debugging commands, like step, next, print var, bt, etc. In my case, GDB shows me (on start): GDB connected. Now you can use usual GDB commands for debugging. Save it as gdb.sh and run it like this (once you powered up your board): $. $GDB -ex 'target extended localhost:4242' $elf_file #!/bin/shĮcho 'Please provide elf-file for debug symbols' >&2 Of course, st-util must be installed, as that script uses it. Perhaps if you follow my instructions, it will work out for you, too.įirst of all, provide next flags to GCC when building your firmware: # Debug flagsĬFLAGS += -Os -g -fno-schedule-insns -fno-schedule-insns2ĬFLAGS += -fno-omit-frame-pointer -funwind-tables I have a similar setup (except for CLion), and I'm able to debug my STM32 board via STM32F4DISCOVERY (which has ST-LINK v2 on it). Lastly, if I use configuration of GDB: Default (Bundled) I don't expect it to work well, but it actually gets further and allows a very limited functionality of pausing/resuming (but with absolutely no other abilities) and does not complain about the symbols

elf symbols load properly direct from command line. If I use arm-none-eabi-gdb direct from command line ( /usr/bin/arm-none-eabi-gdb verified), things work as normal, breakpoints, stepping, etc. gdbinit but gdbinit seems ignoredįurthermore, it does indicate a connection to st-util running remotely, but I am unable to execute any commands (breakpoints, stepping, pause, etc) except for terminate - which does seem to terminate it. Symbol file: /home/malachi/temp/mbed_test/mbed-os-program/BUILD/NUCLEO_F401RE/GCC_ARM/mbed-os-program.elfįrom CLion, no matter what I do, I consistently get this for Console: Cannot configure GDB defaults: No symbol table is loaded. In the GDB Remote Debug config panel, I've set: GDB: /usr/bin/arm-none-eabi-gdb

I read through GDB Monitor commands in CLion providing good insight, but I am having a slightly different issue:

Clion debugger not working