CODEWITHSUNDEEP
gdbstm32cliongdbserver
Malachi
Malachi

Reputation: 2463

GDB + CLion + STM32 - won't remote debug

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

My environment:

In the GDB Remote Debug config panel, I've set:

GDB:         /usr/bin/arm-none-eabi-gdb
Symbol file: /home/malachi/temp/mbed_test/mbed-os-program/BUILD/NUCLEO_F401RE/GCC_ARM/mbed-os-program.elf

From CLion, no matter what I do, I consistently get this for Console:

Cannot configure GDB defaults: No symbol table is loaded.  Use the "file" command.
Debugger connected to localhost:4242

I've tried brute forcing 'file' with a .gdbinit but gdbinit seems ignored

Furthermore, 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.

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. Also .elf symbols load properly direct from command line.

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

Upvotes: 3

Views: 3887

Answers (2)

Malachi
Malachi

Reputation: 2463

Upgrading to CLion 2016.3.3 resolves this issue.

I am experiencing some intermittent slowdown/connection issues but I can't be certain that it's a CLion thing.

Thank you Sam Protsenko and Eldar Abusalimov for your help in this.

Upvotes: 0

Sam Protsenko
Sam Protsenko

Reputation: 14763

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). Perhaps if you follow my instructions, it will work out for you, too.

First of all, provide next flags to GCC when building your firmware:

# Debug flags
CFLAGS  += -Os -g -fno-schedule-insns -fno-schedule-insns2

# Backtrace support
CFLAGS  += -fno-omit-frame-pointer -funwind-tables
CFLAGS  += -mapcs -mno-sched-prolog
LDFLAGS += -mapcs -mno-sched-prolog

Use next script for starting GDB server. Of course, st-util must be installed, as that script uses it.

#!/bin/sh

CROSS_COMPILE=arm-none-eabi-
GDB=${CROSS_COMPILE}gdb

if [ $# -ne 1 ]; then
    echo "Please provide elf-file for debug symbols" >&2
    exit 1
fi

elf_file="$1"

echo '---> Starting GDB server...'
if [ -f gdb.pid ]; then
    kill -9 $(cat gdb.pid)
    rm -f gdb.pid
fi
st-util & echo $! >gdb.pid

echo '---> Starting GDB...'
$GDB -ex "target extended localhost:4242" $elf_file
kill -9 $(cat gdb.pid)
rm -f gdb.pid

Save it as gdb.sh and run it like this (once you powered up your board):

$ ./gdb.sh your-firmware.elf

You'll see (gdb) prompt. Now you can use usual GDB commands for debugging. In my case, GDB shows me (on start):

GDB connected.

reset_handler () at ../../cm3/vector.c:68
68      for (src = &_data_loadaddr, dest = &_data;

So I'm usually do:

(gdb) break main
(gdb) continue
(gdb) list

And then use usual debugging commands, like step, next, print var, bt, etc. Everything works as expected.

Also it should be mentioned that I'm using libopencm3 in my firmware, so it also might have some influence over success of operation. I'd advice you to build and flash some simple example from libopencm3-examples (like this one), and try to debug it with GDB. If it works, and your code doesn't work with GDB, then you can easily look for difference and find the issue.

References

[1] Debugging details

[2] Using ST-LINK with st-util

Upvotes: 4

Related Questions