Hallo, ich möchte an dieser Stelle nochmal bezug nehmen auf diesen post: http://www.mikrocontroller.net/forum/read-2-408840.html#409148 Um das lesen zu ersparen, in aller kürze: Es ging darum daß sich einige Variablen reproduzierbar überschrieben haben, wenn man ihnen werte zugewiesen hat. Am ende der diskussion lag die vermutung nahe, daß es warscheinlich am simulator (AVRStudio) liegt. Ich habe letztendlich 2 Wege gefunden das Problem zu umgehen, die aber jeweils ein anderes Problem auftreten lassen. Womit sich mir die Wahl zwischen 3 Übeln stellt: (A) Compilieren und Linken vermittels AVRStudio Problem: Schrittweises debuggen von Assembler Code ist nicht mehr möglich. (B) Compilieren und Linken vermittels selbst erstelltem Batchfile: Problem: Zeigerübergabe von C nach Assembler funktioniert nicht mehr zuverlässig, da sich variablen überschreiben. Im Beispielprogramm, sieht man dies gut an der Stelle wo die swap variablen im Assemblerteil zurück in die Register geladen werden. (C) Compilieren und Linken vermittels Makefile (via "mfile" erstellt) Problem: Structs funktionieren nicht mehr in der Watchlist. In allen 3 Fällen wird zum debuggen das AVR-Studio benutzt, tests auf der Hardware sind derzeit leider nicht möglich. Ich hoffe es lässt sich eine Lösung finden, in der keines der Probleme auftritt... Sourcen, Batchfile, Makefile finden sich im Anhang. Wietere Dateien Stelle ich gern dazu. Cheers, Leif
Hallo Leif Also ich hab's im AVR-Studio (4.12 SP3) mit WinAVR (20060421) ausprobiert! Hab einige kleine Details angepasst und kann's nun prima compilieren und auch debuggen, sogar auf Assembler Level! Einziger Vermutstropfen: Strukts lassen sich offenbar beim AvrStudio nicht im Watch-Window anzeigen. Oder weiss hier irgend jemand eine Lösung? MfG peter p.s. Anbei meine gezippte Version...
Danke soweit. Allerdings sehe ich keinen wiklichen unterschied zu meiner Version. Ich bin mir auch nciht sicher ob wir unter "Schrittweises debuggen von Assembler" das gleicher verstehen. Ich stelle mir das so vor, daß ich mit F11 in die Assemblerfunktion springe und den dortigen Code zeileweise durchgehen kann. Das gelang mit deiner Version nicht.
Das ist geil! Zuerst eine Überschrift, die NULL Aussagekraft besitzt. Dann ein Link auf einen weiteren Thread, den man sich durchlesen soll, um zu verstehen, welches Problem Du genau hast. Dann ein zip-File, das man erst abspeichern und entpacken soll, um dann (vielleicht!) zu erkennen, wo es bei Dir hakt. Vielleicht kannst Du ja mal etwas besser zusammenfassen, wo Dein Problem liegt? Ich benutze zum Compilieren und Debuggen die Lösung c (Makefile) und habe noch nie Probleme mit Structs im Watchfenster gehabt. Im Gegenteil, das einfache Betrachten von Strcuts und auch Daten, auf die Pointer zeigen, finde ich sehr komfortabel in der gcc/AVR-Studio-Kombination. Vielleicht kannst Du ja auch hier etwas detailierter mitteilen, was "Structs funktionieren nicht mehr in der Watchlist" genau bedeutet. Viele Grüße, Stefan
Gut, die Überschrift ist nicht besonders aussagekräftig... Allerdings ich meine gelesen zu haben, daß man sein makefile sowie sourcen, die auf ein minimu reduziert sind, anhängen soll. Der Post muss ja auch nicht gelesen werden. < was < "Structs funktionieren nicht mehr in der Watchlist" < genau bedeutet. Fügt man das Struct der Watch List hinzu, so erscheint es dort, lässt sich allerdings nicht aufklappen. Die im Struct enthaltenen Werte lassen sich nicht beobachten. Ich meine auch die dort angegebene Adresse des Structs wird nicht korrekt angezeigt, da bin ich mir jetzt allerdings nicht ganz sicher. < Vielleicht kannst Du ja mal etwas besser zusammenfassen, wo Dein < Problem liegt? Gern: Ich habe 3 möglichkeiten ein und denselben Code zu Compilieren und zu Linken. Das Hauptgrogramm ist in C geschrieben und ruft eine in Assembler geschrieben Funktion auf, an die mit Hilfe globaler volatile Variablen Werte übergeben werden. Jede der drei (im folgenden beschriebenen) Variationen des Übersetztens und Linkesn verursacht 1 anderes Problem beim Debuggen mit dem Studio. (Nummerierung wie im obigen Post) (A) Compiliere ich mit dem Studio funktionieren Structs und Zeigerübergabe, aber Assembler Code lässt sich nicht Schrittweise debuggen. (Diese Problem wurde auch schonmal hier diskutiert und führte mich zu Variation (B)) (B) avr-gcc -c -gstabs -mmcu=atmega128 -o dasproblem.o dasproblem.c avr-gcc -Wa,--gstabs -c -mmcu=atmega128 -o mul.o mul.S avr-gcc -g -Xlinker -Map=dasproblem.map -o dasproblem.elf mul.o dasproblem.o avr-objcopy -O coff-ext-avr --debugging dasproblem.elf dasproblem.cof Diese Variante bewirkt, daß ich AssemblerCode Schrittweise debuggen und Structs in der Watchlis betrachten kann, allerdings klappt die Zeigerübergabe an den Assemblerteil nicht mehr. (Dieses Problem wurde hier schonmal Diskutiert, in dem Eingangs erwähnten Post) (C) Das mit "mfile" erstelle Makefile führt zu einem .cof das sich ebenfalls mit dem Studio ausführen läßt. Assembler lässt sich Schrittweise debuggen, Variablemübergabe klappt auch, aber Structs können in der Watchlist nicht mehr aufgeklappt werden. Cheers, Leif
/** Hier der Code der aus dasproblem.c **/ #include <avr/io.h> volatile uint8_t dummy; volatile uint8_t swap1; volatile uint8_t swap2; volatile uint8_t swap3; volatile uint8_t swap4; volatile uint8_t swap5; volatile uint8_t swap6; volatile uint8_t startadresshA1; volatile uint8_t startadresshA0; volatile uint8_t startadresslA0; volatile uint8_t startadresslA1; volatile uint8_t startadresshB0; volatile uint8_t startadresslB0; volatile uint8_t startadresshB1; volatile uint8_t startadresslB1; volatile uint8_t startadresshC0; volatile uint8_t startadresslC0; volatile uint8_t startadresshC1; volatile uint8_t startadresslC1; volatile uint8_t startadresshC2; volatile uint8_t startadresslC2; volatile uint8_t startadresshC3; volatile uint8_t startadresslC3; extern void swapit(); extern void multi(); int main (void){ typedef struct { uint8_t a[20]; //multiplier uint8_t b[20]; //multiplier uint8_t ab[40]; // ab=a*b }mupliva; mupliva mupli; int i; for(i =0; i<=19; i++){ mupli.a[i]=0x41; } for(i =0; i<=19; i++){ mupli.b[i]=0x42; } for(i =0; i<=19; i++){ mupli.ab[i]=0x43; } swap1 = 0xAF; swap2 = 0xFA; swap3 = 0xCF; swap4 = 0xCF; swap5 = 0xDA; swap6 = 0xDB; startadresshC3= 0xDE; multi(); return(0); } /** Hier der Code aus mul.S **/ .stabs "",100,0,0,multi .stabs "mul.S",100,0,0,multi ;;#include "avr/io.h" .extern dummy .extern swap1 .extern swap2 .extern swap3 .extern swap4 .extern swap5 .extern swap6 .extern startadresshA0 .extern startadresslA0 .extern startadresshA1 .extern startadresslA1 .extern startadresshB0 .extern startadresslB0 .extern startadresshB1 .extern startadresslB1 .extern startadresshC0 .extern startadresslC0 .extern startadresshC1 .extern startadresslC1 .extern startadresshC2 .extern startadresslC2 .extern startadresshC3 .extern startadresslC3 .global multi .func multi multi: ;;;;;;;;Initialise;;;;;;;;;;;;;;;;;;;;;;;;;;;;; cli ; disable interrupts push 18 push 19 push 20 push 21 push 22 push 23 push 24 in 24,0x3F ;SREG push 24 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; lds 18, swap1 lds 19, swap2 lds 20, swap3 lds 21, swap4 lds 22, swap5 lds 23, startadresshC3 ;;;;;;;;;;;;;;;;;cleanup;;;;;;;;;;;;;;;;;;;;;;;; pop 24 out 0x3F, 24 ;SREG pop 24 pop 23 pop 22 pop 21 pop 20 pop 19 pop 18 sei ; Enable interrupts ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ret .endfunc // Makefile im Anhang
> ... aber Structs > können in der Watchlist nicht mehr aufgeklappt werden. Das ist wahrscheinlich ein Problem des COFF-Parsers im AVR Studio. Prinzipiell konnte COFF diese Information weiterreichen, aber ich glaube mich an eine Aussage zu erinnern, dass dieses Feature nie implementiert worden ist im AVR Studio. Ich fürchte, die einzige Methode, alles unter einen Hut zu bekommen, ist derzeit die Benutzung des GDB bzw. eines Frontends dazu. Da du aber keine reale Hardware hast sondern nur eine Simulation, rennst du damit an eine andere Schwachstelle: simulavr ist ziemlich spartanisch.
Hallo Leif, wie gesagt, ich benutze die Methode c (nicht ganz, ich habe das Makefile selber gebaut, bzw. das Beispiel-Makefile aus der WINAVR-Installation modifiziert). Damit funktioniert das Debuggen von Structs prima. Allerdings benutze ich nicht das .cof für AVRStudio, sondern das .elf. Wenn ich mich recht erinnere, klappte das Debuggen per .elf-File früher nur mit einer Beta-Version von Atmel-Norwegen. Aber mittlerweile liegt bei Atmel eine neue AVRStudio-Version vor (16. Sept. 2006), mit der es keinerlei Probleme gibt. Ich benutze allerdings nicht den Simulator, sondern debugge direkt auf der Zielhardware per jtag (kann ich übrigens nur empfehlen ...). Ob der Simulator hier eingeschränkter ist, kann ich nicht sagen, würde mich aber wundern. Variante a) habe ich noch nie benutzt, ka wie AVRStudio sein make genau aufbaut. Welche Versionen von WINAVR und AVRStudio benutzt Du? Kannst Du mal versuchen, per .elf File zu debuggen? Viel Erfolg, Stefan
> Kannst Du mal versuchen, per .elf File zu debuggen?
Damit kann er seine Assembler-Dateien nicht debuggen, das ist ja
Teil seines Problems. Ist ein Bug in den GNU binutils, in denen
die Unterstützung für DWARF-2 nicht vollständig implementiert ist.
> > ... aber Structs > > können in der Watchlist nicht mehr aufgeklappt werden. > > Das ist wahrscheinlich ein Problem des COFF-Parsers im AVR Studio. > Prinzipiell konnte COFF diese Information weiterreichen, aber ich > glaube mich an eine Aussage zu erinnern, dass dieses Feature nie > implementiert worden ist im AVR Studio. Variante (b) und (c) produzoeren beide ein .cof. Bei (b) klappts ja mit den structs. Ich habe version (b) und (c) gemischt um herauszufinden welche konkreten parameter welcher GNU tools welche problem beheben/erzeugen. Es scheint alles am umwandeln von .elf in .cof zu hängen. Die spezielle angabe von adressraäumen aus (c) scheitn das prblem der mislingenden zeigerübergabe von (b) an den assembler zu beheben: --change-section-address .data-0x800000 --change-section-address .bss-0x800000 --change-section-address .noinit-0x800000 --change-section-address .eeprom-0x810000 Das das struct nicht mehr funktioniert liegt vermutlich daran, daß (c) im gegensatz zu (b) ein coff und kein extcoff erzeugt. Ersetzt man in version (c) den parameter coff-avr durch coff-ext-avr funktioniert alles ohne einschränkung. (Alternativ kann man das per mfile erzeuge makefile auch mit der option extcoff starten - das sicherlich der schnellste und einfachste Weg, falls noch jemand das gleiche problem hat) Vielen Dank allen die mitgeholfen haben! Cheers, Leif
Jetzt, wo du's sagst, erinnere ich mich: die erste COFF-Version, die AVR Studio verstanden hat, konnte keine structs. Daher haben sie dann irgendwann die erweiterte Spezifikation veröffentlicht, das ist das "extcoff".
Bitte 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.