Running GDB with SES and nRF52840DK

[kw_martin]

RTT seems to be mostly working using the viewer with the command:

JLinkRTTViewer -device nRF52840_xxAA

It seems I need to re-connect each time I start a debug from SES, but this is okay. What I really need thought is to get gdb communicating during a debug. Starting with the command:

JLinkGDBServer -device nRF52840_xxAA -endian little -if SWD -speed 400kHz

seems to connect but then hangs without a prompt, and I can't run any gdb commands, anything typed in the window has no effect. I running under Ubuntu 18.04

> uname -a
Linux granite10192.168.1.23 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

SEGGER J-Link GDB Server V6.73b (beta) Command Line Version

JLinkARM.dll V6.73b (DLL compiled May 15 2020 17:24:15)

Command line: -device nRF52840_xxAA -endian little -if SWD -speed 400kHz
-----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:      yes
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:                 nRF52840_xxAA
Target interface:              SWD
Target interface speed:        400kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 17 2020 14:43:00
Hardware: V1.00
S/N: 683455871
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
Connected to target
Waiting for GDB connection...

[Turbo J]

kw_martin said:

seems to connect but then hangs without a prompt, and I can't run any gdb commands, anything typed in the window has no effect. I running under Ubuntu 18.04

Operating as intended.

You are supposed to connect via arm-none-eabi-gdb, "target remote localhost:2331". You will need to run this on another terminal, as the one with the Jlink GDB server is blocked for JLink diagnostic output.

Edit: The SES debugging probably does this already for you, if you can debug a project in the IDE.

[kw_martin]

This helps; it is what I was missing. I must admit I didn't see it anywhere in the manuals. I am using SES and would prefer to run gdb through the IDE, but the degug terminal is completely blank, so I don't know how to run in the IDE (it is also very small, but I assume I can disattach it and then maybe make the font larger?). If you could give some suggestions on how to get the debug window configured to run gdb in the IDE, it would be appreciated. In the meantime, using JLinkGDBServer, I assume if I run it in the directory that contains main.c, I can load the symbol table using something like >file pca10056/blank/ses/Output/Debug/Exe/twi_sensor_pca10056.elf, and I can put both commands in a .gdbinit file in the same directory as main.c? If you have any links suggesting best practices of using gdb with SES, it would be appreciated. Does having gdb running with breakpoints and watches set slow down RTT? If just breakpoints and no watches are set, is RTT slowed down? If neither watches or breakpoints are set, does the program run full speed except for the RTT overhead? Thanks.

Finally, maybe I should start a new thread for this, but if you have a link for a TWI peripheral example, (not a TWIM) example, it would be appreciated. It seems to me that for initialization, and short data segments, to many different devices, you don't really want a DMA handler, as then you need a mux in the handler to know what device is sending the data? or you need to just wait for completion, with a global wait variable as is done in the twi_sensor project (which should be named twim_sensor?). (Please note these are questions not statements and if I should start new thread for twi vs twim, please let me know.

Finally, finally, thank you for getting back so quickly, your quick replay has saved a lot of time.

[tesc]

Hi,

I see that Segger has some information on using Embedded Studio with GDB Server.

For TWI related questions, please create a separate thread for that. It is definitely a different topic.

Regards,
Terje

[kw_martin]

I have looked at SES GDB LINK but it doesn't seem to work. I have set:

• Debug -> Debugger -> Target Connection to "GDB Server"
• Debug -> GDB Server -> Type to "J-Link"

And I have GDB Server Command Line is "$(JLinkDIR)/JLinkGDBServerCL" -device "$(DeviceName)" -silent.

Information on how to start the gdb client is missing, but with help from Turbo J above, I have in my .gdbinit file:

file pca10056/blank/ses/Output/Debug/Exe/twi_sensor_pca10056.elf
target remote localhost:2331

and I started gdb with

> arm-none-eabi-gdb
GNU gdb (7.10-1ubuntu3+9) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <gnu.org/.../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-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<www.gnu.org/.../>.
Find the GDB manual and other documentation resources online at:
<www.gnu.org/.../>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
0x000089c2 in delay_machine_code.7862 ()
(gdb) b main
Breakpoint 1 at 0x5964: file /home/martin/Dropbox/Nordic/SDK/Workspace/Peripheral/twi_sensor/main.c, line 274.
(gdb) c
Continuing.

The breakpoint at the beginning of main.c is being ignored.

A step-by-step tutorial on how to use gdb with SES would be very helpful.

[tesc]

Hi,

You are attaching to an already running target, since your .gdbinit does not include a reset.

This should give the desired effect:

b main
mon reset
c

That is, you need to reset the target in order to start executing from the "beginning".

Regards,
Terje