Hallo, ich habe ein Problem das sich mir absolut nicht erklären will: ich programmiere aktuell an einem Bootloader für meinen Mikrocontroller. Dazu habe ich mir den Bootloader aus dem Tutorial hier im Forum heraus gepickt und umgeschrieben, sodass er keinen Parser mehr braucht und direkt mit Binärdaten arbeitet. So weit so gut, das Ding funktioniert super, außer wenn ich eine Anweisung in die Switch-Case-Struktur unter den letzten Case (BOOT_STATE_ERROR) einfüge (in diesem Falle einen uart_putc-Funktionsaufruf, aber auch andere Befehle funktionieren nicht). Dann stürzt der Mikrocontroller beim Empfang eines Bytes direkt ab und startet den Bootloader von null. Kommentiere ich den Befehl aus oder lasse den siebten Case komplett leer, gibt es keine Probleme. Ich hoffe jemand kennt das Problem und kann mir weiter helfen, Viele Grüße Christopher
In solchen Fällen ist ein Debugger oder Simulator hilfreich, weil man dann sehen kann, was schiefläuft.
Hallo Chris, das könnte daran liegen, dass der Compiler die switch/case Sprungtabelle an den Anfang des Flashs direkt unter die Interruptvektoren legt (erkennbar an typischen Muster an der Stelle in der *.hex Datei. Wenn dem so ist, dann gehe nach: Project -> Properties -> AVR/GNU C Compiler -> Optimization -> Other Optimization Flags und trage dort ein: -fno-jump-tables
Gast
#4004760
kann es sein das der Code zu groß für den Bootloader Bereich wird?
Hallo, Werde das mit den Compilereinstellungen mal testen. Kommt mir aber seltsam vor, weil ja der Rest der cases funktioniert... Am Speicherplatz kann es nicht liegen, der ist nicht mal halb voll
Hallo nochmal, Dankeschön. Das mit der Compileranweisung hat funktioniert. Perfekt.
Gast
#4004844
Chris K. schrieb: > Hallo nochmal, > Dankeschön. Das mit der Compileranweisung hat funktioniert. Perfekt. so klar ist mir das aber nicht. Wo die Jump-Table liegt entscheidet der Linker. Diese sollte es aber schon richtig machen sonst gibt es früher oder später immer Probleme. Für mich klingt es logischer, das durch die Größe der Jump-Table das Programm zu groß für die Bootloader Bereich wird - egal was die Ausgabe sagt. Kannst du mal von beiden Versionen die Compiler ausgabe und das Map-file posten?
Gast
#4004847
Knut Ballhause schrieb: > das könnte daran liegen, dass der Compiler die switch/case Sprungtabelle > an den Anfang des Flashs direkt unter die Interruptvektoren legt Und wenn dem so ist, warum ist das so? So manch ein peinlich berührter Systemprogrammierer sagte dann bei so einer Gelegenheit: It's not a bug, it's a feature! Ist das ein GCC-Fehler, oder was? Kann das bitte jemand genauer erklären?
Gast
#4004868
Mir scheint, eine Erklärung, warum es ein Problem darstellt, falls die Sprungtabelle direkt unterhalb der Interrupt-Vektoren zu liegen kommt, wäre hilfreich. An sich ist das ja einfach Code. Warum sollte da was schiefgehen?
Rufus Τ. Firefly schrieb: > In solchen Fällen ist ein Debugger oder Simulator hilfreich, weil man > dann sehen kann, was schiefläuft. Ja, das wäre das einfachste. Chris K. schrieb: > Das mit der Compileranweisung hat funktioniert. Nö, es hat nur den Fehler maskiert. Du solltest mal den exakten Typ nennen. Vielleicht ist es ein Problem mit ELPM oder EIJMP bei AVRs >64kB.
Gast
#4004917
Peter Dannegger schrieb: > Nö, es hat nur den Fehler maskiert. Leider hat uns Knut Ballhause nicht gesagt weshalb er auf diese "Problembeseitigung" kommt: Knut Ballhause schrieb: > das könnte daran liegen, dass der Compiler die switch/case Sprungtabelle > an den Anfang des Flashs direkt unter die Interruptvektoren legt.
AVR Angsthase schrieb im Beitrag #4004917: > Leider hat uns Knut Ballhause nicht gesagt weshalb er auf diese > "Problembeseitigung" kommt: Aus Erfahrung. Wir hatten das Problem, dass der Bootloader ein signiertes Firmware-Programm nicht erkannt hat, da die Sprungtabelle den Platz der eigentlichen Signatur belegt hat. Zum Absturz kam es nicht, aber eine feste Adresse enthielt nicht das, was der Bootloader erwartet hätte. Dass es beim TO zum Absturz kommt, liegt vielleicht auch daran, dass an eine fixe Adresse gesprungen wird, die dann nicht mehr existiert. Ohne Code ist das aber nur eine Vermutung.
Hi, Aalso.. Ich komme leider bis Ende der Woche nicht mehr nach hause. ich kann euch von hier aus sowohl das funktionierende als auch das nicht funktionierende HEX-File und die jeweiligen lss-/map-Dateien aus meiner Dropbox ziehen, oder wenn jemand Interesse hat auch das ganze Projekt als Archiv. Mit der Compilerausgabe müsstet ihr euch dann bis Sonntag gedulden. Der Mikrocontroller ist ein AT90CAN128 und der Bootloader-Bereich ist auf 4096kB eingestellt. Hier mal HEX, LSS und MAP von vorhin, als es dann funktioniert hat:
Und hier nochmal von heute nacht, als es nicht funktionierte.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.