Hallo zusammen, ich habe ein relativ komplexes Programm auf dem Mega32. Dieses Programm lebt schon einige Jahre und funktioniert. Nun habe ich mir einen neuen Rechner gekauft - AMD 64 - und habe ein aktuelles Ubuntu laufen. Mit dem Ubuntu kam der avr-gcc 4.5.3 Vorher hatte ich den avr-gcc 4.3.5. Mit dem neuen Rechner, neuen Ubuntu und dem neuen avr-gcc habe ich mein Projekt wieder compiliert. Es gibt keine Fehlermeldungen und das hex, elf usw File wird erzeugt. Soweit alles klar. Das Dumme ist, wenn ich nun das Programm auf den Controller brenne, dann läuft es nicht mehr richtig. Ein Großteil des Programms läuft - aber anscheinend gibt es Probleme mit Interrupt Routinen. Ich verwende SIG_INPUT_CAPTURE1, SIG_OUTPUT_COMPARE1A, SIG_OUTPUT_COMPARE1B Es sieht aus, als ob entweder die Timer nicht laufen, oder die Interrupt Routinen nicht aufgerufen werden. Also habe ich mit dem JTAG-ICE Debugger versucht herauszufinden, wo es hängt. Komischerweise läuft das Programm im Debugger, die IRQ's werden aufgerufen, alles läuft wunderbar. Nur ohne Debugger kommen keine Daten über die IRQ Routinen rein. Ich weiss, dass Euch diese Informationen nicht genügen, den genauen Fehler zu finden. Was ich brauche, ist eine Idee wie ich am besten vorgehe um herauszufinden warum sich das Programm compiliert mit 4.5.3 anders verhält wie mit 4.3.5 compiliert. Vielleicht habe sich ja die gcc Parameter geändert, die Linker Parameter geändert oder etwas in der Richtung ? Aber mir fehlt der Ansatz wo ich die Suche beginnen soll. Ich habe die "alte Toolchain" noch auf der zweiten Festplatte liegen. Also habe ich probiert die Sourcen auf dem neuen Rechner mit dem neuen Ubuntu aber mit der alten Toolchain (gcc-4.3.5) zu compilieren - und alles funktioniert wieder wunderbar. Jetzt könnte ich die 4.5.3 wegwerfen und den alten 4.3.5 Compiler nutzen - aber ich würde schon gerne einen aktuelleren Compiler nutzen. Und ich würde gerne verstehen was ich falsch mache, so dass es mit dem neueren Compiler nicht mehr geht. Hat jemand eine Idee ? Merci Frank
du hast zu 99% einen Fehler im code und durch neue Optimierungen wirken sie sich jetzt aus. immer schön auf volatile und atomic operationen geachtet?
Frank W. schrieb: > Aber mir fehlt der Ansatz wo ich die Suche beginnen soll. In deinem Quellcode. Natürlich gibt es Compilerfehler, aber es ist eher wahrscheinlich dass du einen Fehler gemacht hast, der sich in der alten COmpilerversion nicht augewirkt hat, in der neuen hat aber der Optimizer zugeschlagen und deinen Fehler ausgenutzt. Da du von Interrupt Routinen sprichst: Check mal, ob auch wirklich alle Kommunikationsvariablen als 'volatile' markiert sind.
Ich gehe auch davon aus, dass nicht der böse Compiler der Schuldige ist, sondern dass ich höchste persönlich den Fehler gemacht habe, Kommunikationsvariablen volatile - jein. Ich denke JA - aber ich werde jetzt nochmal genau schauen. Irgendwas in der Richtung sollte es ja sein. Also hab ich offensichtlich doch was übersehen. Merci schon mal Frank
Frank W. schrieb: > Also habe ich mit dem JTAG-ICE Debugger versucht herauszufinden, wo es > hängt. Komischerweise läuft das Programm im Debugger, die IRQ's werden > aufgerufen, alles läuft wunderbar. Nur ohne Debugger kommen keine Daten > über die IRQ Routinen rein. > > Ich weiss, dass Euch diese Informationen nicht genügen, den genauen > Fehler zu finden. Was ich brauche, ist eine Idee wie ich am besten > vorgehe um herauszufinden warum sich das Programm compiliert mit 4.5.3 > anders verhält wie mit 4.3.5 compiliert. Als erstes mal die üblichen Verdächtigen abklappern: * Ist überall voltile, wo es hingehört? * Sind entsprechende asynchrone Zugriffe auch atomar? * Gibt's für das Device Silicon-Bugs, die solche Effekte plausibel machen? * Was ist zeitkritisch? Zugriff mit Debugger ändert das Timing, so daß es evtl. mit Debugger passt, ohne aber nicht mehr. * Has sich was am statischen RAM-Verbrauch geändert?
Ok dann werde ich das alles nochmal checken. Im Debugger mit Breakpoints in den IRQ Routinen ändert sich das Zeitverhalten natürlich grundlegend. Ram Verbrauch - Am Code habe ich 0.0 geändert. Ich habe denn identisch gleichen Sourcecode verwendet. Nur durch andere Compiler gejagt. Ich denke, ich muss wirklich genauer schauen, ob die Zugriffe atomar sind. Das ist ein Punkt, den ich noch nicht vollständig gecheckt habe. Device Silicon-Bugs - selber Chip ( nicht gleicher ), 2 Compiler, anderes Verhalten .... möglich, aber ich denke eher unwahrscheinlich. Danke für die Tipps.
du könntest ja einfach mal beide ASM outputs vergleichen, dann siehst du eventuell stellen die sich zwischen den compieler verändern. Diese stellen kannst du dann genauer untersuchen.
Frank W. schrieb: > Ram Verbrauch - Am Code habe ich 0.0 geändert. Ich habe denn identisch > gleichen Sourcecode verwendet. Nur durch andere Compiler gejagt. Dei Frage war nicht, ob du was am Sourcecode geändert hast (das ist hinreichend klar dargelegt), sondern ob sich was am statischen RAM-Verbrauch geändert hat. Peter II schrieb: > du könntest ja einfach mal beide ASM outputs vergleichen, Vergiss es!
avr-size sagt : 2.3.5
1 | Created stalk.hex for: atmega32 |
2 | text data bss dec hex filename |
3 | 30572 33 1082 31687 7bc7 stalk.elf |
2.5.3
1 | ! Created stalk.hex for: atmega32 |
2 | text data bss dec hex filename |
3 | 29778 33 1082 30893 78ad stalk.elf |
Sieht nicht nach RAM-Änderung aus. Nur Flash ist unterschiedlich.
> du könntest ja einfach mal beide ASM outputs vergleichen,
Das habe ich natürlich mal kurz probiert - aber das gibt es NUR
Unterschiede :-) Das macht - zumindest für mich - wenig Sinn.
Johann L. schrieb: > Frank W. schrieb: > >> Ram Verbrauch - Am Code habe ich 0.0 geändert. Ich habe denn identisch >> gleichen Sourcecode verwendet. Nur durch andere Compiler gejagt. > > Dei Frage war nicht, ob du was am Sourcecode geändert hast (das ist > hinreichend klar dargelegt), sondern ob sich was am statischen > RAM-Verbrauch geändert hat. Die Frage ist wegen einer Optimierung in neueren GCCs: Manche switch/case können zu einer Lookup-Tabelle umgewandelt werden, die in .rodata liegt. Da .rodata bekanntlich im RAM liegt und nicht im Flash, bedeutet das mehr RAM-Verbrauch, was deinen Fehler erklären könnte: http://gcc.gnu.org/PR49857 Der Code könnte dann crashen, weil Stack in die statischen Daten reinwächst. Und der Fehler wird durch anderes, vom Debugger induziertes Laufzeitverhalten maskiert.
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.