using the files I used before, to connect to arm64 board, I tried this.
etri#abss4:~/rrr/u-boot$ cat gdb_script
target remote localhost:3333
set remotetimeout 10
monitor system_init
monitor sleep 2000
monitor soft_reset_halt
load
b main
b board_init_r
and the command is like this.
ddd --debugger aarch64-none-elf-gdb ~/U-BOOT/u-boot/spl/u-boot-spl.elf
I'm not sure if the debugger counter part in the FPGA is working yet.
By the way, the program (u-boot-spl.bin) is loaded to 0x400_0000 by another program and the linker made the .text start at 0x400_0000. I can see the source files in the ddd window.
I see in the telnet window,
accepting 'gdb' connection from 3333
dropped 'gdb' connection
What am I doing wrong??
Related
Trying to debug my sample blink_led code on STM32L476 Nucleo-64 board but gdb can't connect to OpenOCD (connection drops almost instantly with error). I've read plenty of posts here and there but none of them helped. Tried adding commands to OpenOCD using -c but no change of behavior.
My code compiles both in Release and Debug config in Eclipse. I can flash the bin file using drag and drop (while the board has built-in STLink add-on) and looks the code runs perfectly on the board (LED blinks).
Cross compiling on Centos7 using the following versions:
Toolchain (gdb): gcc-arm-none-eabi-8-2018-q4-major
OpenOCD: 0.10.0-11-20190118-1134
As using eclipse didn't work I tried the command line,
(I'm not an experienced developer in this environment so I could not find any config file closer to my stm32l476 board than the stm32l4discovery.cfg, please let me know if there might be some issues using it)
./bin/openocd -f scripts/board/stm32l4discovery.cfg -c "init"
It starts,
GNU MCU Eclipse 64-bit Open On-Chip Debugger 0.10.0+dev-00462-gdd1d90111 (2019-01-18-11:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 500 kHz
Info : STLINK V2J28M17 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.244386
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Then starting GDB:
./arm-none-eabi-gdb ~/eclipse-workspace/test-blink-led/Debug/test-blink-led.elf
then running the following command in gdb:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote connection closed
As it shows gdb connection drops instantly and OpenOCD prompts the following errors:
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080022e6 msp: 0x20017ff8
Info : device id = 0x10076415
Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash
Info : flash size = 1024kbytes
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
Error: jtag status contains invalid mode value - communication failure
Polling target stm32l4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
So from those geeks who do it on a similar platform on a daily basis, can anyone help and tell me where am I doing wrong. Does missing any compile-time flag might result in this problem?
I'm scratching my head for a couple of days now so please let me have your hints.
One of the reasons may be that your STLINK firmware seems pretty old (STLINK V2J28M17 as your log shows). I suggest downloading the STSW-LINK007 application to upgrade the firmware. The software is a multiplatform Java application. It works flawlessly in Debian GNU/Linux.
Currently, I use another gdb server texane/stlink for my debugging task with GDB without any problem on some Nucleo and also custom boards. I use target extended-remote command to join the port of the server. Maybe you can try to connect with this command also under OpenOCD.
Try
telnet localhost 4444
it worked for me, while 3333 didn't
Im trying to attach DDD to gdb on a remote machine. I have configured rsh to not require a pass for my machine & username.
ddd opens with "rtx5:1234: not found" and a pop-up with "GDB could not be started". From calling ddd --host rtx5:2159 --trace --no-exec-window /home/murray/beer-process
# Running GDB (pid 2826, tty /dev/pts/1)...
# Current language: C/C++
# Searching "vsllib/ddd.vsl"...
# Trying "/home/murray/.ddd/vsllib/ddd.vsl"
# Trying "/usr/share/ddd-3.3.12/vsllib/ddd.vsl"
# Searching "vsllib/ddd.vsl"..."/usr/share/ddd-3.3.12/vsllib/ddd.vsl".
<- "sh: line 0: exec: rtx5:2159: not found\n"
# Running GDB (pid 2826, tty /dev/pts/1)...Exit 127.
The PID of GDB started by ddd from the trace logs are 4-digits. However, all the PIDs that I can see from the rtx(target) are 8-digit. I can not see gdb as a process yet the trace log indicates otherwise. Is the documentation out of date and I am invoking it incorrectly? How could I test if ddd is correctly rsh-ing?
I have addressed the caveats of the docs 2.4.1:
Beer-process binary is in the home dir of my username on the target.
Checked the path of gdb in /usr/bin/gdb
rtx5 does not have xterm therefore include --no-exec-window flag
Thanks in advance
TLDR: Had a firewall on the host interfering only with ddd's rsh connection. I also had to substitute "rtx5" for "'rsh rtx5'". It wont find the program I pass it, even though its in the home directory of the remote target. I can however use ddd-gui to find, load, and debug it.
I could rsh to rtx5 without a password, then call gdb.
I could not do "rsh rtx5 gdb" and have gdb start. This is due to rsh. When rsh is called without a command it operates out of 514. If rsh in called with a command it communicates and attempts to move to a different port number. This is where my firewall was blocking it.
Wireshark showed me from local to target after rsh connection:
destination unreachable (host administratively protected)
ddd still has issues primarily that I can not load a binary which is in my remote home directory. This extends problem extends to attaching to running processes on the remote host. In both cases I can load/connect via the gui once the connection is established.
Furthermore I have to call ddd with 'rsh ' prepended to the remote-host name. This seems wrong. I'll update when I have more.
I am remote debugging a Stellaris Launchpad. I use OpenOCD to connect to the stellaris and then connect GDB to the server provided by openOCD. I use Open On-Chip Debugger 0.10.0-dev-00002-g79fdeb3 (2015-07-09-23:28). GDB is the one from arm-gcc-none-eabi, the 4_9-2015q1 release.
I invoke openOCD like this:
/usr/local/bin/openocd --file \
/usr/local/share/openocd/scripts/board/ek-lm4f120xl.cfg \
>> openocdLog.txt 2>&1 &
And then GDB like this:
arm-none-eabi-gdb proj//debug/exec -x gdb//gdb.script
gdb/gdb.script contains:
set remotetimeout 10000
target extended-remote :3333
monitor reset halt
load
monitor reset init
The problem is that whenever I hit control+c GDB disconnects. Normally this would halt the remote, but GDB just disconnects:
(gdb) cont
Continuing.
^CError detected on fd 6
Remote communication error. Target disconnected.: Interrupted system call.
(gdb)
OpenOCD has the following things to say, this one while GDB is launching:
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1258). Workaround: increase "set remotetimeout" in GDB
Which is weird, considering the gdb/gdb.script file forces remotetimeout to an insanly large number.
And when pressing control+c openOCD says:
Debug: 2602 5089 hla_interface.c:119 hl_interface_quit(): hl_interface_quit
So, how do I resolve this? How can I make GDB halt the remote instead of disconnecting when pressing control+c?
The problem was OpenOCD being too bleeding edge. I had issues with 0.6.1, but version 0.7.0 of OpenOCD works great.
I'm trying to debug a program on my board which runs an embedded linux and I have Ubuntu as host system. I have a big problem with gdbserver. You see the thing is that my board doesn't have an Ethernet interface but a serial device which I'm using for console and I noticed that you can use a serial device for debugging in gdbserver although I couldn't find an example of this considering everyone that used gdbserver in videos or books used it in TCP mode which I can't do that.
So What I did was simply running gdbserver on the board this way:
root#DM368# gdbserver /dev/ttyS0 hello
Process hello created; pid = 472
On the host side I'm using ddd program and I ran:
root#mosi-VirtualBox:~# ddd --debugger arm-linux-gdb
And in ddd window terminal I entered:
(gdb) cd /root/home/mySimpleHello/hello
(gdb) target remote /dev/ttyUSB0
(gdb) file hello
And /dev/ttyUSB0 is connected to the board's /dev/ttyS0
But I don't get anything back in gdb and there is nothing in gdbserver output which is kind of weird. I mean not a single message like a "host connected" or "remote debugging from ..." or things like that. And in ddd when I ran:
(gdb) b main
Breakpoint 1 at 0x83ac: file hello.c, line 10.
(gdb) run
Then gdb says:
the program in not being run
I tried with gdb on Ubuntu's terminal directly (whitout ddd) and the same thing happened. I even tried with eclipse and I setup a debugging profile in eclipse and I installed gdb-multiarch program and used that in eclipse with its .gdbinit file set to arm. Nothing happens and I have no idea why this simple procedure wouldn't work.
Does somebody have any idea? What am I doing wrong? How can I debug a program using a serial connection?
I have:
A proprietary prototype ARM board (Cortex-M3 based) with eCos OS
The board has the programmed RedBoot bootloader
Serial line (RS-232)
GDB debugger for ARM (arm-eabi-gdb)
Host OS is Windows/Cygwin and/or Linux (actually, doesn't matter)
Problem: GDB debugger cannot connect to the target over the serial line.
What I want: is to sniff the packets of the GDB remote protocol in order to undestand whether the GDB stub on the target is alive and operating.
Details: RedBoot has an option to pass the target's control to the built-in GDB stub. I know that the RedBoot is alive, I can connect to it and send it commands over the serial line. The RedBoot manual says that the switch to the GDB stub can be made by typing $ or + symbols (which are actually the prefixes of the GDB remote protocol packets). It seems to work for when I send those symbols the terminal dies. But I'm not sure if the RedBoot was compiled with the GDB stub support (don't ask me why :-)).
Then, when I try to connect to the board with my GDB debugger I get the following picture (on Windows):
(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
The port is correct, the baudrate as well. Actually the same output I get if I try to do the same with another serial port which is not connected with anything.
What I want to know is does GDB stub send back anything or not?
Intuitively I thought that probably
set verbose on
would help, but GDB manual says it has very a limited effect and my case is beyond it.
May be it is possible to compile GDB debugger with a macro which enables debug logging?
What I want to know is does GDB stub send back anything or not?
Do this (before target remote):
(gdb) set debug remote 1