edisn wrote:
I am stil searching on information on:
> How to do Debugging on the NXT (nxtgcc using Fantom)
> If a can download a firmware from the IAR-chain.
(It schould be possible using the Fantom from nxtgcc or the version providet by Lego, but i dont get how to configure it correctly)
nxtgcc currently doesn't have the means to debug code executing directly on the NXT yet.
I'm working on a NXT-based instruction level debugger for the NXT Improved Firmware (which should be similar to the nxtgcc firmware) here:
http://git.ni.fr.eu.org/?p=tcwan/nxt-fi ... ;a=summary. (People interested to try it should use commit 953c08633b8d04899c53bc4618c4d50279b27cbd which is what I've used to generate the GDB session trace below -- this is considered as Alpha quality software, so caveat emptor).
There are two parts, one which is built into the modified NXT firmware, and the other is a GDB remote protocol server (nxt-gdb-server.py) which runs on the PC to interface with the GDB debugger. nxt-gdb-server.py depends on nxt-python and associated dependencies (pyusb, libusb). I presume that Eclipse would talk to the GDB server using the GDB remote protocol, but I haven't looked into this yet.
It is still not done yet, but last week I've managed to successfully initiate a gdb exchange with the NXT connected via USB. It is technically possible to get it to work over Bluetooth, but currently the NXT debugger sends its output via USB explicitly. Using the debugger, it would be possible to halt execution of the NXT firmware (and user programs), and examine the contents of registers and memory locations, and continue execution of the user program.
Code: Select all
(gdb) target remote localhost:2828
Remote debugging using localhost:2828
0x001001de in cCommHandleDebug ()
(gdb) info reg
r0 0x0 0
r1 0x201dbe 2104766
r2 0x0 0
r3 0x61 97
r4 0x20fefc 2162428
r5 0x20ad89 2141577
r6 0x20adcd 2141645
r7 0x1e 30
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x40000 262144
r12 0xfffb0054 4294639700
sp 0x20febc 0x20febc
lr 0x1001d7 1049047
pc 0x1001de 0x1001de <cCommHandleDebug+14>
fps 0x0 0
cpsr 0x80000033 2147483699
(gdb) x /16b &__debugger_stack_bottom__
0x201b90: -32 1 16 0 51 0 0 -128
0x201b98: 0 0 0 0 -66 29 32 0
(gdb) cont
Continuing.
Eventually it'll have Assembly Language instruction stepping features for RAM-based programs, but that is not so useful for the NXT firmware since NBC programs execute from Flash. The RAM-based instruction-stepping feature is intended for programs written using NxOS (bare metal programs) .
I guess to debug NBC programs there should be another module on the Host PC side which can convert NBC variable locations into physical address locations. However, I'm not familiar with NBC or the NXT firmware in detail, so if someone is interested in picking this up, it'd be great.
My current issue is the USB communication between the NXT and the PC is not very reliable. I'm testing it using a Fedora 14 VM, but the USB connection tends to lock up since the libusb 0.12.x recv() calls are blocking calls which do not time out. So the GDB server to NXT connection tends to get stuck and I need to restart the GDB server. Nicolas Schodet is trying to write a Python wrapper for the Fantom Drivers so that it would be possible to use nxt-python on the Mac (hopefully Windows as well), which will mean that nxt-gdb-server.py can run on Mac (or Windows) directly. [libusb 0.12.x / 1.0.8 does not work on Mac OSX or Windows to connect to the NXT when I tried to install and use it].