Hi,
ich habe hier ein LPC1768-Board, welches ich gerne per OpenOCD Debuggen
möchte (also ein paar Breakpoints setzen und Variablen untersuchen).
OpenOCD läuft und hat auch schon verbindung zum Board. Dann bin ich nach
der Anleitung unter
http://www.makingthings.com/documentation/tutorial/debug-with-openocd/configure-eclipse
vorgegangen, um mit Eclipse arbeiten zu können.
Allerdings produzieren die dort angegebenen Kommandos bei mir nur
Fehlermeldungen:
target remote localhost:3333
Remote 'g' packet reply is too long:
2b3253542b3253542b3253542b3253542b3253542b3253542b3253542b3253542b325354
2b3253542b3253542b3253542b3253542b3253542b3253542b3253540000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000002b325354
monitor reset
"monitor" command not supported by this target.
monitor wait 500
"monitor" command not supported by this target.
monitor soft_reset_halt
"monitor" command not supported by this target.
monitor arm7_9 force_hw_bkpts enable
"monitor" command not supported by this target.
Scheinbar ist das monitor-Kommando unbekannt. Wie kann ich die
Geschichte sonst noch zum laufen bringen?
Ach ja, ich nutze den Codesourcery ARM-GDB arm-none-eabi-gdb
und was passsiert wenn Du den gdb startest
und diese Kommandos am gdb-Prompt eingibst?
Bevor das nicht geht, musst Du gar nicht mit der Eclipse
kommen.
Dann: Sicherstellen, dass eclipse den CS arm-gdb aufruft und
nicht etwa den Host-gdb.
"monitor" command not supported by this target.
scheint eine Folge des
Remote 'g' packet reply is too long:
zu sein.
Passiert auch dann wenn ich den gdb starte
und ein "monitor" Kommando eingebe, ohne vorher
"target remote" aufgerufen zu haben.
Remote 'g' packet reply is too long:
hatte ich auch schon mit bestimmten CodeSourcery Versionen.
Benutzt Du die Neueste?
dfg schrieb:> hatte ich auch schon mit bestimmten CodeSourcery Versionen.> Benutzt Du die Neueste?
Ja, es ist die aktuellste Version. Ich habe inzwischen herausgefunden,
dass das elf-File eine falsche CPU vorgaukelt. Also das File aus der
Eclipse-Config herausgenommen und die Commands geändert:
target remote localhost:3333
set arch armv5
monitor reset
monitor sleep 500
monitor poll
monitor soft_reset_halt
monitor arm7_9 force_sw_bkpts enable
break PreStackEntry
load firmware/myprog.elf
continue
Jetzt startet er irgend wie ohne die Fehlermeldungen, hängt sich bei 27%
auf und hat mir dabei den Flashinhalt zerschossen.
Meine Frage: ist "armv5" als Architektur für den LPC1768 überhaupt
richtig?
Und wie kann ich das elf-File laden lassen, ohne dass auf dem Flash
rumgepopelt wird?
> Meine Frage: ist "armv5" als Architektur für den LPC1768 überhaupt
richtig?
Selbstverständlich nicht. LPC1768 ist ein Cortex-M3 und
damit ARMv7-M
>Ja, es ist die aktuellste Version. Ich habe inzwischen herausgefunden,>dass das elf-File eine falsche CPU vorgaukelt
Was heisst "falsche CPU"? Woher willst Du das wissen?
Wenn das stimmen sollte, dann hast Du die falschen
Compiler/Linkeroptionen benutzt.
>monitor arm7_9 force_sw_bkpts enable
Dürfte bei CM3 fehl am Platz sein...
dfg schrieb:> Selbstverständlich nicht. LPC1768 ist ein Cortex-M3 und> damit ARMv7-M
Das bietet der gdb aber nicht an, da gibt es nur
arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t,
armv5te, xscale, ep9312, iwmmxt, iwmmxt2, auto
>>Ja, es ist die aktuellste Version. Ich habe inzwischen herausgefunden,>>dass das elf-File eine falsche CPU vorgaukelt>> Was heisst "falsche CPU"? Woher willst Du das wissen?
Seit ich die Architektur explizit setze, sind die
"monitor"-Fehlermeldungen weg
dfg schrieb:> Was heisst "falsche CPU"? Woher willst Du das wissen?> Wenn das stimmen sollte, dann hast Du die falschen> Compiler/Linkeroptionen benutzt.
-mcpu=cortex-m3
Sollte ja passen.
Im übrigen treten die "monitor"-Fehlermeldungen immer dann auf, so bald
das .elf-File im Spiel ist. Aktuell habe ich jetzt das hier:
target remote localhost:3333
set arch auto
monitor reset
monitor wait 500
monitor soft_reset_halt
Damit komme ich auf das Target, er startet mir meinen Code neu, und dann
erhalte ich eine Fehlermeldung "No symbol table loaded, use the file
command". So bald ich aber ein
file firmware/meinprog.elf
anhänge, dann stolpere ich wieder über das Problem mit der Fehlermeldung
"Remote 'g' packet reply is too long". D.h. das ELF-File bringt mir
alles ins stolpern.
> LPC1768-Board, welches ich gerne per OpenOCD Debuggen möchte> [...]> Codesourcery ARM-GDB arm-none-eabi-gdb
Genau diese Kombination habe ich hier am Laufen. Welcher Versionen
benutzt Du?
dfg schrieb:> Irgendein Grund, dass Du mit dem alten Zeug rummachst?
Ja, dem neueren ARM-GCC scheint was elementares zu fehlen:
/usr/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.3/../../../../arm-none-li
nux-gnueabi/bin/ld: cannot find -lcs3
/usr/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.3/../../../../arm-none-li
nux-gnueabi/bin/ld: cannot find -lcs3unhosted
/usr/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.3/../../../../arm-none-li
nux-gnueabi/bin/ld: cannot find -lcs3micro
OpenOCD ist der aktuellste, der mit Fedora 17 mitkommt.
>Ja, dem neueren ARM-GCC scheint was elementares zu fehlen:
Nein.
Bei dem gcc, den ich gerade ausgepackt habe, ist alles da.
Bitte informiere Dich über die "-L" option.
Evtl. liegt es aber auch daran, dass Du bei CS das falsche
Paket heruntergeladen hast. Du
brauchst
arm-2012.03-56-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
>/usr/bin/../lib/gcc/arm-none-linux-gnueabi
deutet drauf, hin, dass Du das Paket für ein Linux Target hast.
Ich bezweifle, dass auf Deinem LPC Board ein Linux läuft.
>OpenOCD ist der aktuellste, der mit Fedora 17 mitkommt.
Das heisst nicht viel. Welche Versionsnummer?
