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...
und ausserdem: CodeSourcery hat ein gdb.pdf dabei. Da sind die meisten Deiner Fragen beantwortet.
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?
arm-none-eabi-gcc (Sourcery G++ Lite 2010.09-51) 4.5.1 GNU gdb (Sourcery G++ Lite 2010.09-51) 7.2.50.20100908-cvs
>Sourcery G++ Lite 2010.09-5 Irgendein Grund, dass Du mit dem alten Zeug rummachst? Aktuell ist: /scratch/jwlemke/2011.09-arm-eabi-lite/src/gcc-4.6-2011.09/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld --with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2011 -D__CS_SOURCERYGXX_MIN__=9 -D__CS_SOURCERYGXX_REV__=69 %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' --enable-languages=c,c++ --disable-shared --enable-lto --with-newlib --with-pkgversion='Sourcery CodeBench Lite 2011.09-69' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/jwlemke/2011.09-arm-eabi-lite/install/arm- none-eabi --with-gmp=/scratch/jwlemke/2011.09-arm-eabi-lite/obj/host-libs-2011.09- 69-arm-none-eabi-i686-pc-linux-gnu/usr --with-mpfr=/scratch/jwlemke/2011.09-arm-eabi-lite/obj/host-libs-2011.09 -69-arm-none-eabi-i686-pc-linux-gnu/usr --with-mpc=/scratch/jwlemke/2011.09-arm-eabi-lite/obj/host-libs-2011.09- 69-arm-none-eabi-i686-pc-linux-gnu/usr --with-ppl=/scratch/jwlemke/2011.09-arm-eabi-lite/obj/host-libs-2011.09- 69-arm-none-eabi-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/jwlemke/2011.09-arm-eabi-lite/obj/host-libs-2011.0 9-69-arm-none-eabi-i686-pc-linux-gnu/usr --with-libelf=/scratch/jwlemke/2011.09-arm-eabi-lite/obj/host-libs-2011. 09-69-arm-none-eabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/jwlemke/2011.09-arm-eabi-lite/install/a rm-none-eabi/bin --with-build-time-tools=/scratch/jwlemke/2011.09-arm-eabi-lite/install/a rm-none-eabi/bin Thread model: single gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-69) und Freunde. Ist Dein OpenOCD auch so alt?
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?
Ich hatte das gleiche Problem mit folgendem Setup - Tools: self compiled Yagarto @ Linux yagarto-bu-2.22_gcc-4.7.1-c-c++_nl-1.20.0_gdb-7.4.1_eabi_20120616 - openocd 0.6.1 - SAM3S (cortex-m3) + JLINK (Atmel SAM-ICE) Der folgende Patch http://pastebin.com/rdFF2eZd löste das Problem, die aktuellen OpenOCD-Quellen mussten allerdings manuell gepatcht werden. Der Link zum Patch stammt von: http://stackoverflow.com/questions/7053067/arm-none-eabi-gdb-and-openocd-malformed-response-to-offset-query-qoffsets (Answer 3).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.