It's alliiiive! (armdebug for NXT Beta 1)
Posted: 23 May 2011, 08:03
Hi,
After much staring at assembly dumps and lots of help from various Mindboards folks, armdebug for NXT Beta 1 is finally working.
http://git.ni.fr.eu.org/?p=tcwan/nxt-fi ... ;a=summary
armdebug is an embedded ARM instruction level GDB debugger for the NXT, which operates using just a USB connection between the NXT and the Host (GDB debugger client). The host is supposed to be cross-platform (Mac, Windows, Linux), using nxt-python to provide the cross-platform support.
For Mac OSX (and probably Windows, I have not tested it on Windows yet), Fantom is the most reliable interface to NXT. Technically the armdebug Host should also work well on Linux, but it has only been tested in a Fedora 14 VM, where I found libusb to have less than satisfactory reliability and performance.
armdebug for NXT is dual licensed, either GPLv2 or LEGO Open Source Licence (to ease integration with other NXT firmware projects which may be interested).
There are several parts to this puzzle:
Currently armdebug for NXT is mostly useful for examining memory contents for the NXT firmware, since code executes directly from Flash and cannot be modified on the fly to support Single Stepping and Dynamically specified Breakpoints (manually specified breakpoints are ok, and one such breakpoint is embedded in my version of the firmware to trigger the Debugger). A more intelligent memory contents viewer can be built on top of the GDB interface but it is beyond the scope of my needs.
(I'll be focusing on NxOS support after this, which will support Single Stepping and Dynamically specified Breakpoints for RAM-resident programs).
A log of my GDB session is found below. I just picked some random routine name and variables from the NXT Firmware code for illustration.
EDIT: Updated URLs for pyfantom and nxt-python (SVN)
After much staring at assembly dumps and lots of help from various Mindboards folks, armdebug for NXT Beta 1 is finally working.
http://git.ni.fr.eu.org/?p=tcwan/nxt-fi ... ;a=summary
armdebug is an embedded ARM instruction level GDB debugger for the NXT, which operates using just a USB connection between the NXT and the Host (GDB debugger client). The host is supposed to be cross-platform (Mac, Windows, Linux), using nxt-python to provide the cross-platform support.
For Mac OSX (and probably Windows, I have not tested it on Windows yet), Fantom is the most reliable interface to NXT. Technically the armdebug Host should also work well on Linux, but it has only been tested in a Fedora 14 VM, where I found libusb to have less than satisfactory reliability and performance.
armdebug for NXT is dual licensed, either GPLv2 or LEGO Open Source Licence (to ease integration with other NXT firmware projects which may be interested).
There are several parts to this puzzle:
- 1. pyfantom (http://pyfantom.ni.fr.eu.org/)
2. nxt-python-fantom, aka nxt-python SVN with fantom support (http://code.google.com/p/nxt-python/source/checkout)
3. nxt-gdb-server.py, which is the Host part of armdebug for NXT http://git.ni.fr.eu.org/?p=tcwan/nxt-fi ... st;hb=HEAD
4. Modified NXT Improved Firmware, based on 1.29 + patches, which is the embedded part of armdebug for NXT, you'll need to rebuild http://git.ni.fr.eu.org/?p=tcwan/nxt-fi ... ;a=summary following Nicolas Schodet's instructions on building the NXT Improved Firmware http://nxt-firmware.ni.fr.eu.org/ for the git repository URL given at the top of this post.
Currently armdebug for NXT is mostly useful for examining memory contents for the NXT firmware, since code executes directly from Flash and cannot be modified on the fly to support Single Stepping and Dynamically specified Breakpoints (manually specified breakpoints are ok, and one such breakpoint is embedded in my version of the firmware to trigger the Debugger). A more intelligent memory contents viewer can be built on top of the GDB interface but it is beyond the scope of my needs.
(I'll be focusing on NxOS support after this, which will support Single Stepping and Dynamically specified Breakpoints for RAM-resident programs).
A log of my GDB session is found below. I just picked some random routine name and variables from the NXT Firmware code for illustration.
Code: Select all
$ arm-none-eabi-gdb nxt_firmware.elf
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10.4.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Users/tcmac/gitrepo/nxt-firmware-tcwan/AT91SAM7S256/SAM7S256/gcc/nxt_firmware.elf...done.
(gdb) target remote localhost:2828
Remote debugging using localhost:2828
0x001001ee in cCommHandleDebug ()
(gdb) info reg
r0 0x0 0
r1 0x201e02 2104834
r2 0x0 0
r3 0x37 55
r4 0x20fefc 2162428
r5 0x20add9 2141657
r6 0x20ae1d 2141725
r7 0x12 18
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x40000 262144
r12 0xfffb0054 4294639700
sp 0x20febc 0x20febc
lr 0x1001e7 1049063
pc 0x1001ee 0x1001ee <cCommHandleDebug+14>
fps 0x0 0
cpsr 0x80000033 2147483699
(gdb) x /4h &BatteryLimits
0x125034 <BatteryLimits>: 6100 6500 7000 7500
(gdb) disass cUiGetString
Dump of assembler code for function cUiGetString:
0x0010e524 <+0>: push {lr}
0x0010e526 <+2>: adds r3, r0, #0
0x0010e528 <+4>: movs r0, #0
0x0010e52a <+6>: cmp r3, #0
0x0010e52c <+8>: beq.n 0x10e546 <cUiGetString+34>
0x0010e52e <+10>: cmp r3, #61 ; 0x3d
0x0010e530 <+12>: bhi.n 0x10e546 <cUiGetString+34>
0x0010e532 <+14>: subs r3, #1
0x0010e534 <+16>: lsls r3, r3, #16
0x0010e536 <+18>: lsrs r3, r3, #16
0x0010e538 <+20>: lsls r0, r3, #4
0x0010e53a <+22>: adds r0, r0, r3
0x0010e53c <+24>: lsls r0, r0, #16
0x0010e53e <+26>: lsrs r0, r0, #16
0x0010e540 <+28>: ldr r3, [pc, #8] ; (0x10e54c <cUiGetString+40>)
0x0010e542 <+30>: adds r0, #8
0x0010e544 <+32>: adds r0, r3, r0
0x0010e546 <+34>: pop {r1}
0x0010e548 <+36>: bx r1
0x0010e54a <+38>: nop ; (mov r8, r8)
0x0010e54c <+40>: andseq r4, r2, r12, asr r5
End of assembler dump.
(gdb) x /16xb &VarsUi
0x20ba6c: 0x4e 0x58 0x54 0x00 0x00 0x00 0x00 0x00
0x20ba74: 0x00 0x01 0x78 0x48 0x01 0x00 0x00 0x00
I definitely have to try this now that I have some free time