(Using STM32F767 microcontroller)
I have a remote debugging environment setup on a RPI using OpenOCD. I can connect to it just fine using GDB.
However since I am writing a bootloader I need to flash the firmware to a specific offset in flash memory. E.g bootloader starts at 0x800000 and firmware should start at 0x8010000 for example so the offset would be (0x10000).
This works fine locally using: mon flash write_bank 0 main.bin 0x10000
But since I don't have the main.bin in the RPI, is there a way I could use OpenOCD or GDB to specify my local file instead and that would be sent over the remote connection?
Note that I would not like to setup a FTP and thus am looking for an alternate solution.
Best regards
gdb should supports sending files to remote via the 'remote put '. But, when I try this in gdb, I get the response "Remote I/O error: Function not implemented". Seems like OpenOCD does not support this
Use "file" to select the file and then "load" will send the file across to the device.
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
I am having trouble getting a reliable debugging setup.
I have seen other threads in some forums across the net with a similar title, but the circumstances seem different.
Setup:
Linux (Xubuntu) 64bit
Eclipse CDT, Neon 4.6.0
"GDB Hardware Debugging" plugin from eclipse "install new software", configured to reset & delay 3sec, halt; load symbols (all checkboxes, no custom commands)
arm-none-eabi-gcc 4.8.3 tool chain
OpenOCD, recently downloaded, running in an own console, configured for my exact MCU with script provided by them & the st-link
STM32L476RG MCU with hard float, which is used.
ST-Link V2 debugger (stand-alone)
Now, there is a sequence with which I am, after some struggle every time, able to connect with the debugger, but stepping and reading variables doesn't work so clearly reliable that I'd trust what I see for a second.
But to even get to that point where the call stack would not be full of obvious nonsense entries and only very few of them, is tiring.
Example:
Flash the device with the firmware. This usually works without trouble.
Start openocd.
Start debugging in Eclipse.
OpenOcd shows connection, then says: "undefined debug reason 7 - target needs reset"
I regardless press the "resume" button in Eclipse to make the program run past the bogus top stack frame it shows.
Press "suspend" (still bogus in callstack), then "terminate".
Ctrl+C out of OpenOcd.
Manually (hardware) reset the stm32 MCU.
Restart OpenOcd.
Start debugging in Eclipse again.
OpenOCD output:
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
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
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.192646
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10076415
Info : flash size = 1024kbytes
undefined debug reason 7 - target needs reset
Now with some luck, I finally have a somewhat working debugger connection, for a while.
But this may as well need some repetitions.
Why the "press resume" in between when it's clear the connection is bad? Not sure, this seemed to increase the likelihood that in the next iteration I'll have the connection, a lot.
A maybe relevant note:
The MCU has an LCD connected to it and from that I can see when it resets.
For some reason, starting debugging in Eclipse will apparently not reset the device, although the reset checkbox is checked in the debug config.
If I open a telnet connection to OpenOCD in a terminal, and do "reset" there, the device does reset.
What could be causes for the odd behavior of my setup?
What OpenOCD client you're using? I made a mistake using the host gdb and I got this error. And after I modified my debugger path to the location of my arm-none-eabi-gdb in "Debug Configuration" of your eclipse the problem disappeared.
From your post you only mentioned you used arm-none-eabi-gcc toolchain, so don't know if you set your gdb to arm-none-eabi-gdb in "Debug Configurations", which is separate from project toolchain settings.
Another version of OpenOCD helped me. Met a similar issue with OpenOCD 0.10.0 from http://gnuarmeclipse.github.io. Initially it worked then the issue appeared. Removed it and installed the build from http://www.freddiechopin.info.
I set up following this guide: http://www.linuxforu.com/2011/03/kgdb-with-virtualbox-debug-live-kernel/
but instead of using the virtual machine, I use 2 real machine:
- one is debugger
- second one is target (with equipped wireless card running ath5k driver)
On the debugger machine, I successfully come into
$gdb
(gdb)target remote /dev/ttyS0
step. Then I use command (gdb)add-symbol-file but there is no /lib/modules/3.9.0/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko
Are there any wrong in this methodology?
I want to debug the ath5k module so do I need to #gdb vmlinux in the fist place?
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
I am trying to debug Linux kernel with kvm vm. I am getting an error message "Remote 'g' packet reply is too long". My host is 64-bit and so is my vm.
My steps:
Start the VM with custom -kernel, -initrd and -append options.
Start gdb
Execute "set architecture i386:x86-64:intel"
Execute "add-symbol-file linux-3.0/vmlinux"
Execute "show arch" to verify its still "i386:x86-64:intel"
Execute "target remote localhost:1234"
Execute "continue"
Press Ctrl+C, I get the above message.
Has anyone faced this problem?
gdb doesn't work well against a cpu that switches between instruction sets at runtime. Wait for the kernel to leave early boot before connecting, and don't use qemu's -S flag.
I also faced same issue, I fixed it by modifying gdbstub.c (in qemu sources) to send 64bit registers always and hinting GDB that architecture is 64bit by passing set arch i386:x86-64
You can check the patch here:
Visit [URL no longer available]
I found a similar problem (& this question) connecting gdb very early in the boot process – as mentioned in other answers, gdb does not very much appreciate the size of registers changing out from under it. This problem can be seen by using set debug remote 1:
(gdb) set debug remote 1
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
...
Sending packet: $g#67...Ack
Packet received: 000000000000000... <~600 bytes>
(gdb) until *0x1000 # at this address we'll be in a different cpu mode
...
Sending packet: $g#67...Ack
Packet received: 10000080000000000000000000000000800000c... <~1000 bytes>
...
Remote 'g' packet reply is too long: 1000008000000000000000000...
(gdb)
Patching gdb to resize its internal buffer when it sees a too-large packet
as found on this issue in the gdb bug tracker (and elsewhere), does indeed work around the problem, as does patching QEMU to only send 64-bit-sized packets. However, the latter solution breaks debugging in non-64-bit-modes, and it seems that the former fix could be incomplete:
It sounds quite wrong to be changing the target behind
GDB's back when GDB is already debugging it. Not just the size
of the g/G packets may change inadvertently, but the layout as well.
If the target description changes with your re-configuration, it
sounds to me like GDB should fetch/recompute the whole target
description. Today, I think that can only be done with a
disconnect/reconnect.
– https://sourceware.org/ml/gdb/2014-02/msg00005.html
The disconnect/reconnect workaround mentioned at the end of the post does appear to work:
(gdb) disconnect
Ending remote debugging.
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
(gdb) info registers
rax 0x80000010 2147483664
rbx 0x0 0
...
I had accidentally omitted the binary name as an argument to gdb. So this worked for me.
$ gdb ./vmlinux
(gdb) target remote localhost:1234
And then got the Output :
Remote debugging using localhost:1234
0xffffffff81025f96 in default_idle ()
The debugger needs vmlinux so make sure you provide it. OP has a different problem, But my answer might help to those who forgot to provide argument to gdb and ended up with the same error message as OP.