Friday, February 23rd 2018, 3:36am UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

E70tryhard

Beginner

Date of registration: Feb 21st 2017

Posts: 5

1

Tuesday, February 21st 2017, 3:51pm

[SOLVED] GDB server - read data structures while target is running

Hello,

is ist possible to configure a setup for:
a) Segger GDB Server connection via JLink to target (Cortex-M7)
b) GNU ARM arm-none-eabi-gdb client connected to it
b1) where program execution is not interrupted (in any way even for the shortest amount of time)
b2) getting gdb client to perform "print my_data_structure" while target is running

?

So far I only managed to get the following:
- Connection to target via JLink
- GDB connection out of Eclipse via "GDB SEGGER J-Link Debugging"; I could also connect the gdb client purely from command line (without any difference)
- get it connected to the target
- but I always do see an interruption / halt
- (followed by a continue)
- when connected to the target and it is running, I am not able to enter a command to the gdb client, since it seems to be "locked by the gdb server"
- only if I halt the target, I can write commands via the gdb client

Did I overlook some config options?

If I want to read from / write to target memory without any sort of interruption / halt I have to connect to the running target with J-Link Commander (then use commands like mem32, w4) ... and therefore I lose the advantage of having GDB in combination with the ELF file (for "automatic symbol to address conversion" ... e.g. "(gdb) print my_data_structure")

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

2

Wednesday, February 22nd 2017, 9:37am

Hi,


there are multiple options:

1)
You can use the monitor commands in the GDB-Client to directly pass commands to the J-Link software. e.g. "monitor memU32 0x20000000" in order to read 4 Bytes from 0x20000000.
The monitor commands are documented in UM8001 chapter "J-Link software and documentation package", section "J-Link GDB Server", subsection "Supported remote (monitor) commands".

2)
You can use an IDE or debugger which supports monitoring of variables during run time on Cortex-M target, e.g. SEGGER embedded Studio or Ozone - the J-Link Debugger.

3)
You can start the debug session as usual with J-Link GDB Server and Client, and then use the "Connect to running target" feature of J-Scope in order to track variables in RAM.

Quoted

when connected to the target and it is running, I am not able to enter a command to the gdb client, since it seems to be "locked by the gdb server"

This sounds unusual. Which GDB Client do you use? Could you sent us a screenshot of this behavior?


Best regards,
Niklas
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

E70tryhard

Beginner

Date of registration: Feb 21st 2017

Posts: 5

3

Wednesday, February 22nd 2017, 11:21am

Hi,

Thanks for the reply.

Quoted

when connected to the target and it is running, I am not able to enter a command to the gdb client, since it seems to be "locked by the gdb server"
Seems to me like it has something to do with the combination of Eclipse + Eclipse GNU ARM + JLink Debug plugin + GNU ARM 5.4 arm-none-eabi-gdb.exe + JLinkGDBServerCL.exe. Not sure what causes the problem. I can enter the commands in the Eclipse console for arm-none-eabi-gdb.exe, but they do not execute during run, only when I halt the target in Eclipse.


Just to make sure I ran the following lines directly from command-line completely skipping Eclipse:

SEGGER: JLinkGDBServerCL.exe -Device ATSAME70N20 -if SWD -speed 4000 -noir -nohalt
Output of JLinkGDBServerCL.exe:
JLinkARM.dll V6.12j (DLL compiled Feb 15 2017 18:01:10)

-----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: ATSAME70N20
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V9 compiled Dec 16 2016 15:34:10
Hardware: V9.10
S/N: XXXXXXXXXXXXXX
Feature(s): GDB
Checking target voltage...
Target voltage: 3.28 V
Listening on TCP/IP port 2331

GNU ARM arm-none-eabi-gdb.exe: file myProg.elf
GNU ARM arm-none-eabi-gdb.exe: target extended-remote localhost:2331

Output of JLinkGDBServerCL.exe:
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
...Target halted (PC = 0x20400474)

In command window of GNU ARM arm-none-eabi-gdb.exe:
(gdb) monitor go


from there on the system executed the code, and running the "print myVar" command worked as expected / desired while the mcu was in run.
Question left is: why is the target halted when the gdb client connects to the server? are there any options/commands to prevent this?

E70tryhard

Beginner

Date of registration: Feb 21st 2017

Posts: 5

4

Thursday, February 23rd 2017, 1:22pm

From the SEGGER GDB Server (v6.12j) log you can see, that as soon as the GDB Client (launchpad gnu arm 5.4 2016q2 arm-none-eabi-gdb.exe) connects the function JLINK_Halt() gets called.

...
03-00000000-00-00000560-001D: Waiting for GDB connection...
02-00000000-00-00002416-0049: T25CC 002:466 JLINK_GetHWStatus(...) returns 0x00 (0002ms, 0521ms total)
...
02-00000000-00-01216453-004A: T25CC 1216:502 JLINK_GetHWStatus(...) returns 0x00 (0003ms, 2545ms total)
03-00000000-00-01217435-0016: Connected to 127.0.0.1
03-00000000-00-01217649-0015: Reading all registers
02-00000000-00-01217653-0045: T1964 1217:701 JLINK_IsHalted() returns FALSE (0004ms, 2549ms total)
02-00000000-00-01217685-0040: T1964 1217:705 JLINK_Halt() returns 0x00 (0032ms, 2577ms total)
02-00000000-00-01217685-0044: T1964 1217:737 JLINK_IsHalted() returns TRUE (0000ms, 2577ms total)
02-00000000-00-01217685-0051: T1964 1217:737 JLINK_ReadReg(R15 (PC)) returns 0x20400402 (0000ms, 2577ms total)
03-00000000-00-01217694-0022: ...Target halted (PC = 0x20400402)
02-00000000-00-01217694-004B: T1964 1217:746 JLINK_ReadReg(R0) returns 0x2045FEC0 (0000ms, 2577ms total)
02-00000000-00-01217694-004B: T1964 1217:746 JLINK_ReadReg(R1) returns 0x2045FEBE (0000ms, 2577ms total)

What is the reason for this behaviour?
Is there any way to prevent / supress this function call? In my case this call messes up the timings with other chips on my board, which in the end leads to a non-observable state of the system.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 716

5

Thursday, February 23rd 2017, 2:03pm

Hi,

Quoted

What is the reason for this behaviour?

At least older versions of GDB required the target to be in a known state on connect,
which is: The target is halted and the register values are known.
Therefore GDB Server halts the target and reads the registers.

What you want to do is "attach" to the application running on your target and evaluate its current state, correct?

To not halt the target and to not initialize the registers, there are the command line options you already used manually: -noir -nohalt

After GDB is connected to GDB Server, the GDB Server will not do anything with the target,
so halt or any other commands are issued by GDB.

Please note, that when GDB connects to a running application, or any time when the application is running, you cannot issue any other command prior to halting the target.

To read variable values while the target is running, there are different options:
- Open a second connection to GDB Server and use the GDB Protocol commands to read memory
- Use another debugger which is capable of reading variables while the target is running, for example Ozone, which is available free of charge for use with J-Link PLUS
- Use J-Scope, which can read and display variable values with high speed while the target is running.

Please note, that when you use the monitor commands, the GDB client does not update its internal state, so with monitor go it does not "know" that the target continued.

Best regards
Nino

E70tryhard

Beginner

Date of registration: Feb 21st 2017

Posts: 5

6

Friday, February 24th 2017, 11:44am

Concerning the GDB client: I used version 7.12.0 which should be a farily new one.

Today I set up the connection via OpenOCD and it worked right away without ever halting the target.
Meaning:
a) In order to get OpenOCD to find the SEGGER J-Link I switched the USB driver to "Libusb - WinUSB".
b) Connected with OpenOCD and the same SEGGER J-Link adapter to my target (ATSAME70)
c) OpenOCD created the GDB server
d) connected the same GDB client (version 7.12.0) to the OpenOCD GDB server
e) GDB successfully connected without halting the target
f) GDB command "print myVar" worked as expected

Therefore I am not sure as to how this relates to your post concerning "After GDB is connected to GDB Server, the GDB Server will not do anything with the target".

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 377

7

Monday, February 27th 2017, 5:29pm

Quoted

Therefore I am not sure as to how this relates to your post concerning "After GDB is connected to GDB Server, the GDB Server will not do anything with the target".

This means, the J-Link GDB Server sets up the connection to J-Link and target, and waits for the GDB connection.
When GDB Server is started with -noir -nohalt, the target will still be running.

When GDB connects to GDB Server, the target is still running, but the first thing GDB tries to do, is to read all CPU registers.
To do this, GDB Server needs to halt the target.
This is what you see in the GDB Server Log

Quoted

03-00000000-00-01217649-0015: Reading all registers
...
03-00000000-00-01217694-0022: ...Target halted (PC = 0x20400402)
...

Not sure why GDB needs to read the CPU registers, or how to prevent this.
It looks like with OpenOCD either the registers are not read or OpenOCD returns invalid registers.

Quoted

e) GDB successfully connected without halting the target
f) GDB command "print myVar" worked as expected

With OpenOCD you can issue commands while the target is running?
The default behavior of GDB is, that when the target application is running, after attach or continue command, it does not take any other command until you hit Ctrl-C or a breakpoint is hit.

Regards
Johannes

E70tryhard

Beginner

Date of registration: Feb 21st 2017

Posts: 5

8

Tuesday, February 28th 2017, 7:48am

In OpenOCD console:

Quoted

GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-
18:48)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
atsame70n20
Warn : Interface already configured, ignoring
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : flash bank command
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Info : J-Link V9 compiled Dec 16 2016 15:34:10
Info : Hardware version: 9.10
Info : VTarget = 3.282 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bd11477
Warn : Silicon bug: single stepping will enter pending exception handler!
Info : atsame70n20.cpu: hardware has 8 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0xa1020c00
undefined debug reason 7 - target needs reset


Looks like OpenOCD is not reading the registers.
in GDB client console

Quoted

(gdb) target remote :3333
Remote debugging using :3333
0x00000000 in ?? ()
(gdb) print gpTC1->TC_CV
$1 = 33348
(gdb) print gpTC1->TC_CV
$2 = 51339

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 377

9

Thursday, March 2nd 2017, 6:27pm

Quoted

(gdb) target remote :3333
Remote debugging using :3333
0x00000000 in ?? ()

The last line should tell that the target is halted (at 0 in this case, which is in an unknown function)
But since your variable gpTC1->TC_CV changes, it seems that your target is still running. Correct?

This shows that OpenOCD does not behave "correct" but seems to fake the current target status and probably the register read, too.

Since J-Link GDB Server is used by various IDEs which rely on a correct target state we cannot fake this and will halt the target when GDB wants us to do this.

So if you really require this behaviour, you will have to use OpenOCD or switch to a non-GDB debugger like Ozone.

Best regards
Johannes