I'm using an Olimex ARM-USB-OCD dongle with openOCD and GDB to program and debug an stm32f103 micro. The IDE I'm using came from the Olimex dev-kit CD and makes use of eclipse ganymede.
I can load a small program into the RAM and step through the code without any problems.
I now have a much larger program which doesn't fit into RAM (which is only 20K) and so I'd like to run it from flash (which is 128K).
I've modified the linker script indicating the program code should go in the flash section (address 0x8000000), but gdb fails to load the program.
(gdb)
20 load main.out
&"load main.out\n"
load main.out
~"Loading section .text, size 0xb0e6 lma 0x8000000\n"
Loading section .text, size 0xb0e6 lma 0x8000000
&"Load failed\n"
Load failed
What should I do to get gdb to load the program into flash?
Have you considered flashing directly with openocd? I am doing this in a similar setup, but with an ARM7 microcontroller.
openocd -f flash.cfg
Here is my flash.cfg
set CHIPNAME at91sam7x512
source [find interface/olimex-arm-usb-ocd.cfg]
source [find target/at91sam7sx.cfg]
init
halt
flash probe 0
flash probe 1
flash erase_sector 0 0 15
flash erase_sector 1 0 15
flash write_image my-image.elf
at91sam7 gpnvm 0 set
at91sam7 gpnvm 1 set
at91sam7 gpnvm 2 set
shutdown
The GPNVM stuff is Atmel SAM7 specific, but I think this script should give you a good starting point for making a STM32 version. Openocd can be a bit confusing in the beginning, but the documentation is good and worth reading (http://openocd.berlios.de/). The current stable version (0.4.0) is quite old, so if you have problems, download the latest source code and compile your own.
Related
I'm trying to debug a Raspberry Pi Pico project using openOCD + Picoprobe. I go through the steps that appear to be correct to do all this from my Linux PC (the Get started with Pico and C++ guide is for the Raspberry Pi, but there are tutorials online for PC), but when trying to set breakpoints in gdb, it appears to be looking at a different file.
My steps are the following:
In a console, navigate to the openOCD folder and run:
sudo src/openocd -s tcl/ -f tcl/interface/picoprobe.cfg -f tcl/target/rp2040.cfg
I get only info messages, no errors, until it waits for the gdb to connect
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Then, in a different console, I navigate to what I want to debug, in this case the blink.c example. I stand inside the build folder with my .elf file and run
sudo gdb-multiarch blink.elf
(gdb) target extended-remote localhost:3333
(gdb) monitor reset init
(gdb) break 15
where 15 is a relevant debuggable line. But the thing is, the breakpoints are said to be set in a different file:
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461
and then on, all breakpoints are also set there. Here's an example trying to set 3 different breakpoints:
(gdb) b 15
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 16
Note: breakpoint 1 also set at pc 0x20000178.
Breakpoint 2 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 17
Note: breakpoints 1 and 2 also set at pc 0x20000178.
Breakpoint 3 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
So that. I am totally lost on what's happening here. Could anyone point me to why this is happening, or what that file does?
I see it's been a few months but I just ran into the same problem, here's what I've learned.
When you compile the C/C++ program that you're trying to debug, you need to compile it in debug mode, which tells the compiler to include debug symbols in the program. If compiling directly with gcc, you can use the -g flag. However, I'm assuming you're using CMake, in which case you can just add set(CMAKE_BUILD_TYPE Debug) to your CMakeLists.txt (found a few other options here as well)
Probably goes without saying, but after recompiling this way, you'll need to re-load your new program onto your target Pico by holding the bootsel button and plugging it into your machine directly (ie. not via your debugger Pico).
I also found that after doing this, setting breakpoints just to specific lines still didn't behave as expected, and I had to actually specify the name of the file as well, ex: break main.c:15
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'm using an embedded PC which has a Vortex86-SG CPU, Ubuntu 10.04 w/ kernel 2.6.34.10-vortex86-sg. Unfortunately we can't compile a new kernel, cause we don't have any source code, not even drivers or patches.
I have to run a small project written in C++ with OpenFrameworks. The framework compiles right each script in of_v0071_linux_release/scripts/linux/ubuntu/install_*.sh.
I noticed that in order to compile against Vortex86/Ubuntu 10.04, the following options must be added in every config.make file:
USER_CFLAGS = -march=i486
USER_LDFLAGS = -lGLEW
In effects, it compiles without errors, but the generated binary doesn't start at all:
root#jb:~/openframeworks/of_v0071_linux_release/apps/myApps/emptyExample/bin# ./emptyExample
Illegal instruction
root#jb:~/openframeworks/of_v0071_linux_release/apps/myApps/emptyExample/bin# echo $?
132
Strace last lines:
munmap(0xb77c3000, 4096) = 0
rt_sigprocmask(SIG_BLOCK, [PIPE], NULL, 8) = 0
--- SIGILL (Illegal instruction) # 0 (0) ---
+++ killed by SIGILL +++
Illegal instruction
root#jb:~/openframeworks/of_v0071_linux_release/apps/myApps/emptyExample/bin#
Any idea to solve this problem?
I know I am a bit late on this but I recently had my own issues trying to compile the kernel for the vortex86dx. I finally was able to build the kernel as well. Use these steps at your own risk as I am not a Linux guru and some settings you may have to change to your own preference/hardware:
Download and use a Linux distribution that runs on a similar kernel version that you plan on compiling. Since I will be compiling Linux 2.6.34.14, I downloaded and installed Debian 6 on virtual box with adequate ram and processor allocations. You could potentially compile on the Vortex86DX itself, but that would likely take forever.
Made sure I hade decencies: #apt-get install ncurses-dev kernel-package
Download kernel from kernel.org (I grabbed Linux-2.6.34.14.tar.xz). Extract files from package.
Grab Config file from dmp ftp site: ftp://vxmx:gc301#ftp.dmp.com.tw/Linux/Source/config-2.6.34-vortex86-sg-r1.zip. Please note vxmx user name. Copy the config file to freshly extracted Linux source folder.
Grab Patch and at ftp://vxdx:gc301#ftp.dmp.com.tw/Driver/Linux/config%26patch/patch-2.6.34-hda.zip. Please note vxdx user name. Copy to kernel source folder.
Patch Kernel: #patch -p1 < patchfilename
configure kernel with #make menuconfig
Load Alternate Configuration File
Enable generic x86 support
Enable Math Emulation
I disabled generic IDE support because I will using legacy mode(selectable in bios)
Under Device Drivers -> Ethernet (10 or 100Mbit) -> Make sure RDC R6040 Fast Ethernet Adapter Support is selected
USB support -> Select Support for Host-side USB, EHCI HCD (USB 2.0) support, OHCI HCD support
safe config as .config
check serial ports: edit .config manually make sure CONFIG_SERIAL_8250_NR_UARTS = 4 (or more if you have additional), CONFIG_SERIAL_8250_RUNTIME_UARTS = 4(or more if you have additional). If you are to use more that 4 serial ports make use config_serail_8250_MANY_PORTs is set.
compile kernel headers and source: #make-kpkg --initrd kernel_image kernel_source kernel_headers modules_image
when I run gdbserver on uclinux target device blackfin bfin537/stamp it work perfectly but it always generates annoying output
Request to get for unknown register 232
Request to get for unknown register 236
it is extremely annoying since each step out or step in gdb client results several of that error on the output screen terminal RS232 I was recommended to change the bfin compiler version and rebuild gdb server with different version of uclinux ,.... none of them worked and even compiling my code with different versions of bfin-uclinux-gcc didn't solve my problem.
I decided to recompile gdbserver.c and eliminate the line that generates the error but in fact that line does not exists in any of the gdbserver related files for compiling.
I decided to suppress the stderr output of gdb server by running gdbserver :3298 process 1>/dev/null 2>/dev/null but this didn't solve it
how can I configure my gdb client to asks for specific registers (bfin-uclinux-gdb) related to bfin537-stamp?
I think this error originates somewhere else in uclinux system background system processes.
I want to find which process writes in stderr,stdout which I am unaware of It and I want to suppress its outputs?
Shall I change something in the busybox shell or /bin/bash to eliminates all stderr outputs
which means if I send all the parent shell output or stderr to /dev/null
Thanks
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.