I have successfully set up gdb to debug stm32 on Clion.
However, it's only able to flash the .elf on to the target, Clion exits the debugging mode immediately when the flashing is done.
I would like of course to have the ability to properly debug using breakpoints, etc
Here are the debugging properties :
I believe I should put something in target remote args and that all my problem arise from here. I've tested with target extended-remote \\.\COM5 but it ended with a failure
Content of the args file :
target extended-remote \\.\COM5
monitor swdp_scan
attach 1
load
set mem inaccessible-by-default off
run
Here is the Clion console :
arm-none-eabi-gdb.exe cmake-build-debug\EPUCK2Test.elf --interpreter=mi --command=cmake-build-debug\args
=thread-group-added,id="i1"
~"GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.2017112
8-git\n"
~"Copyright (C) 2017 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\
nThis is free software: you are free to change and redistribute it.\nThere is NO
WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show wa
rranty\" for details.\n"
~"This GDB was configured as \"--host=i686-w64-mingw32 --target=arm-none-eabi\".
\nType \"show configuration\" for configuration details."
~"\nFor bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
~"Find the GDB manual and other documentation resources online at:\n<http://www.
gnu.org/software/gdb/documentation/>.\n"
~"For help, type \"help\".\n"
~"Type \"apropos word\" to search for commands related to \"word\"...\n"
~"Reading symbols from cmake-build-debug\\EPUCK2Test.elf..."
~"done.\n"
#"Target voltage: ABSENT!\n"
#"Available Targets:\n"
#"No. Att Driver\n"
#" 1 STM32F40x M3/M4\n"
=thread-group-started,id="i1",pid="1"
=thread-created,id="1",group-id="i1"
~"HAL_GetTick () at D:/Data/Dev/Minor/STM32/EPUCK2Test/Drivers/STM32F4xx_HAL_Dri
ver/Src/stm32f4xx_hal.c:326\n"
~"326\t}\n"
*stopped,frame={addr="0x08000744",func="HAL_GetTick",args=[],file="D:/Data/Dev/M
inor/STM32/EPUCK2Test/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c",fullname
="D:\\Data\\Dev\\Minor\\STM32\\EPUCK2Test\\Drivers\\STM32F4xx_HAL_Driver\\Src\\s
tm32f4xx_hal.c",line="326"},thread-id="1",stopped-threads="all"
+download,{section=".isr_vector",section-size="392",total-size="49699"}
+download,{section=".isr_vector",section-sent="392",section-size="392",total-sen
t="392",total-size="49699"}
+download,{section=".text",section-size="4264",total-size="49699"}
+download,{section=".rodata",section-size="20",total-size="49699"}
+download,{section=".ARM",section-size="8",total-size="49699"}
+download,{section=".init_array",section-size="8",total-size="49699"}
+download,{section=".fini_array",section-size="4",total-size="49699"}
+download,{section=".data",section-size="1084",total-size="49699"}
=cmd-param-changed,param="mem inaccessible-by-default",value="off"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
=thread-group-started,id="i1",pid="42000"
=thread-created,id="1",group-id="i1"
*running,thread-id="all"
com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: To open a remote debug connection, you need to specify what
serial device is attached to the remote system
(e.g. /dev/ttyS0, /dev/ttya, COM1, etc.).
Debugger disconnected
Process finished with exit code 0
GDB Server stopped, exit code 1
The end of the log is quite odd, it looks like for some reason gdb has been disconnected from the target
com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: To open a remote debug connection, you need to specify what
serial device is attached to the remote system
(e.g. /dev/ttyS0, /dev/ttya, COM1, etc.).
Debugger disconnected
What is even stranger is that there is no such "disconnection" when running the very same command arm-none-eabi-gdb.exe cmake-build-debug\EPUCK2Test.elf --interpreter=mi --command=cmake-build-debug\args directly in the terminal.
Thanks in advance for your help
The problem you are seeing is probably related to https://sourceware.org/bugzilla/show_bug.cgi?id=28711
Related
I want to debug gtest ut exec file. but it failed to use aarch64-poky-linux-gdb run.
my host is x86 environment, and my compile environment is arm64.
This GDB was configured as "--host=x86_64-pokysdk-linux --target=aarch64-poky-linux".
I used this cmd to run
$ aarch64-poky-linux-gdb --args ./unittests/ut_settings --gtest_filter=SettingsTestSuite.testParseStatus
$ file ut_settings
ut_settings: ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=cb6d795bd316fb829ddd26caf317240532105469, for GNU/Linux 3.14.0, with debug_info, not stripped
but when i typed run, it cannot run
(gdb) r
Don't know how to run. Try "help target".
but is use ctest it can run, so i guess it can be use gdb debug, but i don't know how to. can some one help me how to run it
the entire log
$ aarch64-poky-linux-gdb --args ./unittests/ut_settings --gtest_filter=SettingsTestSuite.testParseStatus
GNU gdb (GDB) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pokysdk-linux --target=aarch64-poky-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./unittests/ut_settings...
(gdb) r
Don't know how to run. Try "help target".
(gdb) help target
Connect to a target machine or process.
The first argument is the type or protocol of the target machine.
Remaining arguments are interpreted by the target protocol. For more
information on the arguments for a particular protocol, type
`help target ' followed by the protocol name.
List of target subcommands:
target core -- Use a core file as a target.
target exec -- Use an executable file as a target.
target extended-remote -- Use a remote computer via a serial line, using a gdb-specific protocol.
target record-btrace -- Collect control-flow trace and provide the execution history.
target record-core -- Log program while executing and replay execution from log.
target record-full -- Log program while executing and replay execution from log.
target remote -- Use a remote computer via a serial line, using a gdb-specific protocol.
target tfile -- Use a trace file as a target.
Type "help target" followed by target subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Type "apropos -v word" for full documentation of commands related to "word".
Command name abbreviations are allowed if unambiguous.
Okay I have this issue for quite some time now because I never found a solution online.
I thought I will ask here and hope if someone else also encountered this issue (and with a little luck solved it).
So the expected behavior of those buttons starting with the left circled one is that the code is compiled, flashed and runs on the embedded hardware. The second circled one is the same as previous but will listen to breakpoints and start a gdb server.
When pressing the first button it will fail with the following error message:
[0mOpen On-Chip Debugger 0.10.0 (2020-07-29) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlin
k.cfg
Info : auto-selecting first available session transport "hla_swd". To override u
se 'transport select <transport>[0m'.
Info : The selected transport took over low-level target control. The results mi
ght differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.218361
Info : STM32F439VIT6.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32F439VIT6.cpu on 3333
Info : Listening on port 3333 for gdb connections
semihosting is enabled
Error: The 'tcl_port' command must be used before 'init'.
But when pressing the second button (debug), it will flash, run the code and start a gdb server all without problems.
The tooling used is:
OpenOCD (version: OpenOCD-20200729-0.10).
Clion (version: 2021.1 but problem persists on previous version) as my IDE.
mingw64 installed via msys.
arm gdb debugger (version 8.3.1)
If you have an idea what the problem could be, please let me know. I can keep using debug without breakpoints but it is annoying as hell that I just can't run.
Somewhere down the line a fix was needed for something.
# Enable semihosting at startup
# Dirty fix for https://youtrack.jetbrains.com/issue/CPP-7103
init
arm semihosting enable
Commenting the init and arm semihosting enable line fixed the problem.
Still weird it would work in debug configuration but not in run configuration. If someone knows why exactly. Please leave an answer in the comments or a post.
Happy coding :)
I tried to setup the gdb debugger today which was already a hassle in itself. Now that it works (I can launch it at least) it gets stuck none of my commands have any effect on the debugger. I launch the debugger like so:
$ g++ main.cpp -g
$ gdb ./a.out
I can run layout next when I type run it just doesn't respond anymore.
I put an infinite loop in my program on purpose to see simulate a bug. Even without the loop its the exact same behavior.
It also doesn't say "done" when reading in the compiled file:
Now when I try to start gdb without any files specified. This is what happens:
➜ gdb
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin20.1.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file ./a.out
Reading symbols from ./a.out...
Reading symbols from /Users/Documents/coding/C++/testing_c++/testing_c++/a.out.dSYM/Contents/Resources/DWARF/a.out...
../../gdb/thread.c:95: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
../../gdb/thread.c:95: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
I'm trying to get remote debugging working in QEMU for the sifive_u machine. All tools are from the Arch Linux repositories:
➜ qemu-system-riscv64 --version
QEMU emulator version 4.2.0
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
➜ riscv64-linux-gnu-gdb --version
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
I'm starting the machine as follows:
qemu-system-riscv64 -M sifive_u -m 256M -bios default -nographic -S -s
When I connect the debugger, I attempt to continue execution, but nothing happens; if I detach the debugger, the OpenSBI splash prints to the serial console. A typical gdb session looks something like this:
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=riscv64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000000000001000 in ?? ()
(gdb) info thread
Id Target Id Frame
* 1 Thread 1.1 (sifive-e51-riscv-cpu harts[0] [running]) 0x0000000000001000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000000080005a52 in ?? ()
(gdb) info thread
Id Target Id Frame
* 1 Thread 1.1 (sifive-e51-riscv-cpu harts[0] [halted ]) 0x0000000080005a52 in ?? ()
(gdb) detach
Detaching from program: , process 1
Ending remote debugging.
[Inferior 1 (process 1) detached]
It seems odd that I can only see a single thread in info thread; I would expect to see one thread per hart.
My hunch is that I end up attached to a hart which loses the lottery and goes to sleep, and for some none of the other harts are allowed to continue execution. If I use the virt machine, the execution starts as expected when I run continue and I see the OpenSBI splash immediately, so it seems to be linked to the use of the sifive_u in some way.
Does anyone have any idea what I'm doing wrong?
https://www.qemu.org/docs/master/system/gdb.html#Debugging%20multicore%20machines
See "Debugging multicore machines" in this page.
(gdb)target extended-remote :1234
(gdb)add-inferior
(gdb)inferior 2
(gdb)attach 2
(gdb)i threads
See this picture
I'm trying to read the MCUs ADC register using GDB but I can't seem to find how it's done.
Using x\10x 0x40012708 in gdb just returns zeroes, as do any memory mapped peripheral register I try to read.
It this possible to do? If so, how is it done?
Thanks!
I would suggest to validate that your setup is functional first.
For example, you could try to read the CPUID register which is present on all Cortex-M0 processors - see section 4.3 of the Cortex™-M0 DevicesGeneric User Guide.
It is located at address 0xE000ED00, and it shall contain value 0x410CC200.
If you can read it, this would be a good sign.
You probably should try using J-Link commander first, then with GDB-Server and GDB. I ran the procedure hereafter on an Olimex board using an LPC1114/301 Cortex-M0. I was using J-Link software V5.10n, and arm-none-eabi-gdb version 7.10.1.20151217-cvs, which is part of Linaro gcc 5.2 for ARM Cortex-M processors package.
Start JLink.exe using the following options:
jlink.exe -if SWD -speed 4000 -AutoConnect 1 -device Cortex-M0
You should see something similar to:
SEGGER J-Link Commander V5.10n (Compiled Feb 19 2016 18:39:46)
DLL version V5.10n, compiled Feb 19 2016 18:39:11<br/>
Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: [My J-Link EDU Serial Number]
License(s): FlashBP, GDB
OEM: SEGGER-EDU
Emulator has Trace capability
VTref = 3.313V
Device "CORTEX-M0" selected.
Found SWD-DP with ID 0x0BB11477
Found Cortex-M0 r0p0, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl 0 # E00FF000
ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
Cortex-M0 identified.
J-Link>
You can now read the CPUID register using the J-Link commander mem32 command, and verify the CPUID register does contain the expected value:
J-Link>mem32 0xE000ED00,1
You should get:
E000ED00 = 410CC200
If this is the case, I would say that your J-Link/Cortex-M0 setup is likely functional. We can now verify GDB Server and GDB are working fine too.
Launch JLinkGDBServerCL.exe with the following options: JLinkGDBServerCL.exe -if SWD -speed 4000 -device Cortex-M0
SEGGER J-Link GDB Server V5.10n Command Line Version
JLinkARM.dll V5.10n (DLL compiled Feb 19 2016 18:39:11)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: Cortex-M0
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: [My J-Link EDU Serial Number]
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.31 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Keep the GDB server running, and start GDB in an other Windows console session:
arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
We can now connect to GDB server, and attempt to display the content of the CPUID register again:
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0xfffffffe in ?? ()
(gdb) monitor halt
(gdb) monitor reset
Resetting target
(gdb) x/1xw 0xE000ED00
0xe000ed00: 0x410cc200
(gdb)
If you are getting 0x410cc200 again, your J-Link/Cortex-m0/GDB Server/GDB setup should be functional, and you should now try again to read your ADC register using this command:
x/1xw 0x40012708
If you were able to read the CPUID register, but not the ADC register, and if the address for the ADC register is correct, I would not have an explanation for this behavior right now - knowing the exact brand/model for the MCU you are using could of course help further.
Please note that from now on, you should specify the exact model for your MCU as the argument to the -device J-Link Commander/GDB Server options instead of Cortex-M0. You can get the list by entering command ? on the J-Link Commander command-prompt.