Hallo, Kann mir bitte jemand sagen, wie ich meine AVR-Assembler Programme unter Linux debuggen kann??? Es gibt ja den simulavr der mit Verbindung mit gdb bzw. avr-gdb funktioniert, nur das Problem liegt darin, daß er keine .hex sondern nur .out Dateien akzeptiert. Mit AVR-GCC kann ich ja auch solche erzeugen und das klappt mit simularvr auch gut, aber assembler, die ich ausprobierthabe (avra, tavrasm, gavrasm) wollen keine .out Dateien erzeugen :-( AVRStudio krieg ich mit Wine auch nicht am laufen... Muß ich wirklich Windows installieren um meine Programme zu debuggen ? Danke für die Aufmerksamkeit Sebastian
Danke, daß mein Beitrag verschoben wurde... So habe ich auch Antwort auf meine Frage gefunden :-D Und zwar, nur falls das jemanden interessiert avr_simulator, gibt es bei sourceforge, scheint ganz gut zu sein, werde es jetzt mal Testen, danke nochmals, auch fur keine Antworten :-) Gruß Sebastian
und was haben deine Tests so gezeigt? oder bist du noch dabei?
Hallo Henning, Auf den ersten Blick war ich positiv von dem Programm überrascht, die einfachsten Sachen hat es gut simuliert (Register setzen und lesen) Aber dann habe ich mir gedacht, daß ich zu doof bin einen Timer mit Interrupts zu Programmieren, weil der Timer zwar lief, aber keine Interrupts ausgelöst hat :-( Habe mein Timerprogramm heute auf einer Windoof Kiste unter Studio laufenlassen und es klappt super, also liegt es an avr_simulator, vieleicht stimmt was nicht mit den Vektoradressen oder so, schade eigentlich, ich habe schon gedacht, ich habe endlich meinen Simulator gefunden.... Kann auch sein, daß ich irgendwo einen Fehler bei der Installation gemacht habe, das kann ich mir aber nicht so vorstellen, vielleicht gibt es jemanden, der das Programm kennt und auch was dazusagen kann? Achso, ich habe den ATMEGA 8 simuliert, heute versuche ich es mit dem 16 vieleicht geht es dann Gruß Sebastian
Erstens sollte klassisches simulavr auch ihex-Dateien lesen können, da
die zugrundeliegende libbfd das kann. Die Option -F suggeriert
zumindest, dass man ein Dateiformat angeben kann, eventuell
funktioniert sogar eine automatische Erkennung.
Zweitens muss man simulavr eigentlich gar keine Datei mitgeben, wenn
man ihn mit dem GDB nehmen will, da man das Programm auch stets aus
dem GDB in den Simulator laden kann.
GDB wiederum basiert auch auf libbfd und kann damit auch ihex-Dateien
lesen. Allerdings fehlt ihm dann jegliche Information über den Inhalt
des zu debuggenden Targets, da ihex keinerlei Symboltabellen mit sich
bringt. Aber funktionieren tut's:
% avr-gdb -q delaytest.hex
(no debugging symbols found)
(gdb) info file
Local exec file:
`/home/joerg/src/avr/test/delaytest.hex', file type ihex.
Entry point: 0x0
0x00000000 - 0x00001758 is .sec1
(Hier könnte man mit "target remote" zum Simulator verbinden und mit
"load" das Image in den Simulator pumpen.)
Inwiefern das auch mit dem Nachfolger simulavrxx tut, hab' ich jetzt
keine Ahnung. Meines Wissens kann man den auch noch nicht unter
Windows compilieren lassen.
@Jörg Danke für Deine Antwort, aber genauso habe ich es gemacht, also den simulavr als gdb server process gestartet mit der Angabe von dem Device und dann in den gdb selber die .hex Datei geladen. Nur wenn ich damit den simulavr füttern will krieg ich folgende Fehlermeldung: Memory access error while loading section .sec1. und wenn ich den simulavr mit der option -F hex starte, kommt das: Only the bin file format is currently implemented. Sorry. Also doch keine hex Dateien, leider Gruß Sebastian
Ja, sieht so aus, als würde simulavr nur binary files unterstützen. Was machst du denn mit dem GDB? Das funktioniert hier OK: % simulavr -g -d atmega128 & [2] 90418 Simulating a atmega128 device. MESSAGE: file decoder.c: line 3872: generating opcode lookup_table MESSAGE: file main.c: line 413: Simulating clock frequency of 8000000 Hz Waiting on port 1212 for gdb client to connect... % avr-gdb -q delaytest.hex (no debugging symbols found) (gdb) targ rem :1212 Remote debugging using :1212 Connection opened by host 127.0.0.1, port -3538. 0x00000000 in ?? () (gdb) load Loading section .sec1, size 0x1758 lma 0x0 Start address 0x0, load size 5976 Transfer rate: 47808 bits in <1 sec, 192 bytes/write.
Hallo, @OldBug Ja genauso mache ich das, allerdings nicht mit .elf sondern mit .hex, weil mein Assembler keine .elf oder .out Dateien erzeugt. @Jörg Den gdb starte ich genauso, wie Du auch mit dem target und load allerdings kommt dann die Fehlermeldung mit dem Speicher(sehe meinen letzten Beitrag). Vielleicht liegt das an der simulavr Version? Ich benutze die Originalversion von Debian sid, und zwar 0.1.2.2, hast Du eine andere? Soll ich eventuell was anderes ziehen und selber Kompilieren? Bei meinen C Programmen funktioniert der gdb auch ohne Probleme, wird dann wohl an simulavr liegen, oder? Gruß Sebastian
Hallo, habe exakt dasselbe Problem mit simulavr 0.1.2.2-1. Wenn sich hier irgend eine Lösung ergeben haben sollte dann wäre ich für eine Info sehr dankbar :-)
Ich habs jetzt mit tavrasm und anderen Formaten (generic hex, obj, bin) versucht, das Ergebnis ist das selbe. Hab auch einen anderen Simulator (AVR-sim von der Uni Magdeburg) probiert, dort gibts überhaupt einen Segfault. avrora ist ein anderer Simulator, damit hab ich aber noch gar nix zuwegegebracht Hmmm, bleibt mir "wieder" nur die Windoofs Software? Grüße aus Wien Armin
Hast du mal simulavrxx probiert? Ich selbst noch nicht, aber es halt allgemein gute Kritiken.
Hello. (My German writing is bad, so thats why in English, sorry) You should try an older version of gdb with simulavr. For me, 6.0.0 works fine but 6.3 and 6.2 do not work. Also the 'info io_registers' works with older versions, but not with newer ones. Hope this helps, even though this thread is already 2 months old. Best regards, Johan
> You should try an older version of gdb with simulavr. For me, 6.0.0 > works fine but 6.3 and 6.2 do not work. I don't have any trouble with GDB 6.3. > Also the 'info io_registers' works with older versions, but not with > newer ones. Patch can be found here: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/avr-gdb/files/patch-gdb%3a%3aremote.c?rev=HEAD&content-type=text/plain I'm afraid I forgot to file that as a bug report to GDB so far.
> I don't have any trouble with GDB 6.3. Ermmm, mind that second patch there in my FreeBSD port as well: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/avr-gdb/files/patch-gdb%3a%3asymfile.c?rev=HEAD&content-type=text/plain
Hello. I applied the patch to gdb6.3, and the 'info io_registers' is working. The debugging seems to work, with registers and local variables changing values. However, I still get a mamory access error when loading the file: (gdb) target remote :1212 Remote debugging using :1212 0x00000000 in __vectors () (gdb) load Loading section .text, size 0x7a lma 0x0 Memory access error while loading section .text. (gdb) Any ideas? Best regads, Johan
Hello. I've been trying simulavr and simulavrxx in conjunction with avr-gdb over the past couple of days. The results with the older simulavr have been really nice. However I don't seem to find a way to use input ports on it (PINA, etc..). Simulavrxx seems to be better when it comes to attaching external virtual hardware, but I miss the simulavr-disp tool, and the 'info io_registers' GDB command on this one. Am I missing something here? Should the 'info io_registers' work with simulavrxx? How do I connect something (e.g. switch) to an input on the old simulavr? Maybe someone here has experience with this and could help me. Best regards, Johan
Quite possible that simulavrxx doesn't handle the `info io_register' command; this command indeed needs to be handled by the backend GDB connects to. I only know that AVaRICE also doesn't handle the IO registers for all target MCUs. Remember though that you can still query a single IO register quite fine by dereferencing its address explicitly. So (gdb) x/32x 0x800020 will display the values of the first 32 IO registers, and (gdb) p/x *(char *)0x800039 will display the value of PINA, for example. Remember also that you can use GDB-internal variables, so e.g. the above could also be written by (gdb) set $pina=(char *)0x800039 ... (gdb) p/x *$pina or also (gdb) display *$pina so it will display you the contents of PINA each time the debugger stops. It seems simulavrxx might need a helping hand in some areas... It's probably best to discuss things like that one with the authors on their mailing list: http://lists.nongnu.org/mailman/listinfo/simulavr-devel
Hello. Thanks for the information. I have subscribed to their mailinglist, maybe I can help them out with some stuff. By the way, in case anyone is interested, the reason why I could not read any data into a port (e.g., data = PINB) is because the external device hooks to ports have been disabled in the emulavr main.c Re-enabeling these inputs makes this work again. Best regards, Johan
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.