arm-none-eabi-gdb und openocd: Fehlerhafte Antwort von offset-Abfrage qOffsets?

Ich bin versucht, den Gebrauch von GDB zum Debuggen von einem Stellaris LM3S8962 Evaluation board mit OpenOCD und der GNU-ARM-toolchain (die mit MacPorts installierten), immer wenn ich das remote-Ziel in GDB, es gibt immer "Malfomred Antwort auf offset-Abfrage qOffsets". Irgendwelche Ideen auf, was könnte schief gehen? Gibt es etwas, dass ich vermisst werde?

[bcochran@narada arm]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.3
Copyright (C) 2011 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.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) file ~/dev/eclipse_workspace/hello_world_arm/bin/main.axf
Reading symbols from /Users/bcochran/dev/eclipse_workspace/hello_world_arm/bin/main.axf...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: {{}~Open On
Nak
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: Chip Debugger
> 
Ack
Packet received: qSupported:qRelocInsn+
Packet qSupported (supported-packets) is supported
...
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: qOffsets
Malformed response to offset query, qOffsets

Hier ist die Ausgabe von openocd... sobald die fehlerhafte Antwort kommt über openocd fällt die telnet-Verbindung...

[bcochran@narada bin]$ openocd -f ../openocd/luminary.cfg -f ../openocd/stellaris.cfg
Open On-Chip Debugger 0.6.0-dev-00014-g827057f (2011-08-09-22:02)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
Error: error during read: Connection reset by peer
Info : dropped 'telnet' connection

Hier die version Ausgänge von meinem arm-none-eabi-* toolchain...

[bcochran@narada tcl]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-none-eabi/4.6.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.1/configure --prefix=/opt/local --target=arm-none-eabi --enable-languages=c,objc,c++,obj-c++ --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/arm-none-eabi-gcc --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --enable-multilib --with-newlib --enable-interwork
Thread model: single
gcc version 4.6.1 (GCC)

[bcochran@narada tcl]$ arm-none-eabi-gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 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.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Ich bin in der Lage zu kompilieren mit der toolchain und flash die resultierende .bin-Datei mit OpenOCD. Ich habe nicht in der Lage war, eine Lösung zu finden, um die "fehlerhafte Antwort" - Problem nur durch die Suche im web.

Vielen Dank im Voraus für jeden Rat oder Hilfe!

UPDATES

Dank, die Antworten von @turbo-j und @guy-sirton, ich war in der Lage, um die Fortschritte ein wenig weiter... Die meisten hilfreich so weit war, dass ich in der Tat mit dem falschen port (4444 statt 3333), aber jetzt bin ich immer die folgenden, ob ich hinzufügen -c "init" -c "halt" -c "reset halt" zu meiner openocd Kommando-string oder nicht:

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote 'g' packet reply is too long:     0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c118c03040d6f0284dbb93204b40c2000000000c010020ffffffff550400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000001

(dies ist direkt nach der qOffsets req/resp, was jetzt passiert)

Auf der OpenOCD-Seite:

Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Info : dropped 'gdb' connection

Manchmal mit einer undefined debug reason 6 - target needs reset auf der OpenOCD console...nicht sicher, was jetzt genau Los ist, aber es scheint näher zu funktionieren

UPDATES 2

Es scheint, wenn ich nicht laden Sie die Datei 'main.axf' oder 'Haupt -.o' ich nicht, laufen Sie in die Remote 'g' packet reply is too long aber ich bekomme keine Symbole... ich habe bemerkt, andere websites befassen sich vorwiegend mit dem .elf-Erweiterung. Was ist der Unterschied? Ich bin mit dem "Hello World" - Beispiel von StellarisWare, die es erzeugt main.axf main.bin (flash schreibt und läuft einwandfrei), main.d, wichtigsten.o aus der make Befehl. Etwas merkwürdiges über meine Makefile?