Application debugging on ARM7TDMI embedded systems
This article describes the steps to be followed to debug applications on embedded ARM7TDMI processors using the GNU Debugger 'GDB' and gdbserver.
Embedded systems typically have memory constraints that restrict the size of executables (with debug information) and debuggers stored in ram. A stripped executable binary of much smaller size is usually placed on the target board, while the executable with debugging information remains on the host development system. Similarly since GDB is a large and sophisticated debugger, a light-weight control program gdbserver was created to be run on the target system.
gdbserver is executed along with the stripped application on the target machine. GDB is loaded on the host system along with the unstripped application, containing debug symbols. GDB communicates with gdbserver via a serial port or TCP/IP to provide a full-fledged debugging environment. In this article a GUI front-end debugger, Data Display Debugger 'DDD' is used.
Support for application debugging is present in the latest uClinux kernels. GDB for ARM7TDMI is typically available with the arm-elf toolchain.
The gdbserver application present in the uClinux distribution however, does not work for ARM7TDMI targets. gdbserver for ARM7TDMI must be built from source. The following post by Bernhard Kuhn details the steps to build arm-elf-gdb and gdbserver from source. Binaries for arm-elf-gdb and gdbserver may be downloaded instead.
The gdbserver application present in the uClinux distribution may also be patched to provide ARM7TDMI support. Refer this post by Eric Hammerle for more details.
DDD may be downloaded here and built on the host machine.
During the uClinux build process, two executables are created for every user application: 'app' and 'app.gdb'. The former is a smaller sized executable without any debug information and is copied to the target. The latter contains debug symbols and remains on the host system. gdbserver must also be loaded on the target.
To proceed with the debugging:
- Enter the directory on the target board where the stripped application, 'app' resides and start gdbserver:
gdbserver comm_device application [arguments...]
Here, comm_device is the device connecting the target board to the host system. This may be a serial device or a TCP hostname and port number if the target board is connected to a network. Sample commands include:
gdbserver /dev/ttyS0 app input.datgdbserver 192.168.1.3:1234 app input.dat
gdbserver :1234 app input.datThe hostname parameter is currently ignored by gdbserver.
- One the host machine, enter the directory where the unstripped application 'app.gdb' resides, and start 'arm-elf-gdb':
arm-elf-gdb app.gdb
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...Enter the command (target remote comm_device) in the GDB console to connect to gdbserver running on the target. comm_device is either the serial device name which connects the host system to the target, or the IP address and port number of the target board.
(gdb) target remote /dev/ttyS0(gdb) target remote 192.168.1.2:1234
Debugging can then proceed from the GDB console.
- DDD may be used over arm-elf-gdb if a graphical font-end is desired. Once gdbserver is started on the target, DDD may be executed from the user application directory as follows:
ddd --gdb --debugger "arm-elf-gdb" app.gdb
If arm-elf-gdb is not found by DDD, the full path to arm-elf-gdb must be specified. Once DDD loads up, connect to gdbserver using the target command as detailed in step 2.
Comments:
Comments are closed for this post.