Helfen Sie mir beim Debuggen: Flash-Programmierung erfolgreich und verifiziert; Programm läuft nicht

Ich versuche, einen einfachen Bootloader im High-End-Flash eines atmega8 zusammenzustellen. Der Loader kommuniziert mit minicom über das XMODEM-Protokoll, sucht nach Fehlern, schreibt die entsprechenden Flash-Seiten und verifiziert diese. All dies ist getestet und funktioniert.

Was nicht funktioniert, ist das Ausführen der Anwendung, nachdem sie geflasht wurde. Ich habe 4 Testfälle.

Wenn die Eingabedatei 1 KB mit 0x00- oder 0x01-Bytes ist, scheint die Programmausführung nach einem Kaltstart beim Bootloader zu beginnen, obwohl das BOOTSEL-Bit so eingestellt ist, dass es bei der Flash-Adresse 0x0000 beginnt und der Loader bei 0x1800 ist.

Wenn die Eingabedatei eine Binärdatei eines tatsächlichen Programms ist, hängt der Chip und es ist keine Kommunikation möglich. Ich habe es mit einer sehr einfachen und einer ziemlich komplexen Anwendung versucht, und das Ergebnis ist das gleiche.

avr-gcc app.c -o app.out
avr-objcopy -j .text -j .data -O binary app.out app.bin  # doesn't work
avr-objcopy -j .text -j .data -O ihex app.out app.hex  # works via an isp

.hexWährend beide Programme durch das Hochladen der Datei über einen systeminternen Programmierer auf Funktionsfähigkeit überprüft wurden , führt das Hochladen der .binDateien zu dem erklärten Hängen.

Hier sind zum Beispiel die ersten paar Bytes der sehr einfachen Anwendung:

00000000  12 c0 24 c0 23 c0 22 c0  21 c0 20 c0 1f c0 1e c0  |..$.#.".!. .....|

Dies ist Big-Endian und wird vom Bootloader in Small-Endian konvertiert. Der Opticode eines RJMP ist 1100 kkkk kkkk kkkkein kOffset von bis zu 2 kB. So 12 c0wird c0 12, was wird 1100 0000 0001 0010. Die Vektortabelle ist also da.

Was könnte falsch sein? Mir gehen die Ideen aus. Und meine einzigen Debugging-Hilfen sind printf()über uart und das Blinken einer LED - kein JTAG verfügbar. Wo soll ich nach der Lösung suchen?

Wenn Sie keine Live-Debugging-Funktion haben, könnten Sie vielleicht einen Simulator ausprobieren?
Erwartet der Bootloader das .bin- oder .hex-Format? Ich habe keine AVR-Erfahrung, aber Freescale / Motorola-Bootloader erwarten normalerweise das .s19-Format, das für Menschen lesbares ASCII mit Adressen und Prüfsummen anstelle der rohen Binärdaten ist. Überprüfen Sie auch, dass Sie nicht versuchen, den Bootloader-Bootblock zu überschreiben, wenn Sie den neuen Code schreiben. Dies ist möglich, wenn der Bootloader entweder keine Prüfung/Schutz hat oder die hochgeladenen Daten ihn anweisen, an der ursprünglichen Adresse zu schreiben.
...können Sie alternativ ein Entwicklungsboard mit Debugging-Fähigkeit kaufen, das denselben oder einen sehr ähnlichen Chip enthält, mit dem Sie dieses Problem lösen können?
@JohnU, der Bootloader nimmt nur Bytes aus dem uart und schreibt sie in den Flash. Es erwartet also definitiv eine Binärdatei, aber möglicherweise nicht die Binärdatei, die ich ihr gebe (übrigens ihexist es auch ein für Menschen lesbares ASCII). Ich suche nach Überlauf des Bootsektors. Zu Ihrem zweiten Kommentar, dies ist ein sehr kleines Projekt, aber ein ausgeklügeltes Entwicklungsboard scheint der letzte Ausweg zu sein.
@ pjc50, als ich das letzte Mal (vor Jahren) nachgesehen habe, war der AVR-Simulator sehr begrenzt, insbesondere konnte er außer der CPU keine Hardware simulieren ... und ein Mikrocontroller besteht hauptsächlich aus Peripheriegeräten. Ich denke, dies ist mein vorletzter Ausweg, bevor ich ein hoch entwickeltes Entwicklungsboard kaufe.
Hmm. Fügen Sie Ihrem Bootloader eine "Überwachungs" -Funktion hinzu, damit er den gesamten Inhalt des Flashs nach dem Schreiben ausgeben kann, damit Sie ihn überprüfen können?
Hast du den Bootloader geschrieben? Haben Sie einen Link zur Dokumentation oder zum Quellcode? Selbst sehr einfache Demo-/Entwicklungsboards implementieren oft brauchbares Debugging, also lohnt es sich, zu prüfen, was es da draußen gibt. Wenn es Ihnen die Arbeit eines Tages erspart, ist es das Geld eines Tages wert.

Antworten (1)

In einer solchen Umgebung mit geringen Debugging-Ressourcen muss jedes Tool verwendet werden. In meinem Fall war dies der In-Circuit-Programmer . Ich habe es verwendet, um Bilder des Blitzes herunterzuladen.

 sudo avrdude -p atmega8 -c usbasp -U flash:r:file_name:r

Dann dhexwurde die Verwendung von Bytewertunterschieden offensichtlich, was zu dem Schluss führte, dass die Flash-Programmierfunktionen von avr-libc unsigned chars erwarten und ich signierte chars verwende.

Ja, mein allererster Bootloader funktioniert.

Helfen Sie mir beim Debuggen: Flash-Programmierung erfolgreich und verifiziert; Programm läuft nicht
AntwortenHierDatenschutz-Bestimmungen1y, 0v