Fehler beim FAT Bootloader

Ich habe auf einem Demoboard den Fat Bootloader in Betrieb nehmen können, dabei sind mir einige Fehler aufgefallen, die man vielleicht beheben kann, mir haben sie viel Zeit gekostet.

BootLoaderID
Einmal ist es, wie schon in einem anderen Beitrag geschrieben, sehr verwirrend, dass in der Doku einmal von BootID, LoaderID und BootLoaderID gesprochen wird, aber immer das selbe gemeint ist.
Dass die Konstante "BootLoaderID" heißen muss steht da zwar im Text, aber man sollte noch darauf hinweisen, dass sie exakt so geschrieben sein muss, Groß/Kleinschreibung ist dabei wichtig.


FAT_Bootmode
In der Demo Xmega_FATBoot steht im Define folgendes



Auch wenn ich das auf "plain" stehen lasse wird ein verschlüsselter Code entschlüsselt.
Wozu dient also der Bootmode "aes"? Er hat keine Wirkung wie es scheint.


AES Verschlüsselung
Dann gibt es einen Errorcode "bootAESerr". Wozu dient er?

Ich habe mal probiert was passiert wenn eine falsch verschlüsselte oder unverschlüsselte Datei geladen wird.
Wenn ich im Code oder im Loader eine falsche AES Signatur angebe merkt der Loader nichts!
Er schreibt munter drauf los und schreibt dann natürlich totalen Müll ins Flash. Spaßigerweise ist das Device dann hinüber, weil er danach auch die Speicherstelle im eeprom auf $00 setzt und beim nächsten Reset der Loader dann versucht das korrupte Programm zu starten!
Der spätere Anwender darf das Gerät dann einschicken damit man das eeprom löschen kann, ganz üble Sache.

Ist es irgendwie möglich eine falsch verschlüsselte Datei zu erkennen und das Schreiben zu unterbinden?

Ist es möglich das Setzen von EEprom[EEpromEnd] = $00 nach dem Flashen zu verhindern?
Dann würde ich das in der eigentlichen Software machen, um sicher zu gehen dass es nur bei korrekt laufender Software auch gesetzt wird. Schlägt ein Flashvorgang fehl, weil z.B. die Datei auf der SD-Card defekt war, landet man so immer wieder im Loader bis es geklappt hat. Das wäre sehr viel sicherer.

Ich schicke z.T. Geräte nach Australien, das wird teuer wenn sich da eins aufhängt.

ie Checksumme sieht vielversprechend aus, so wie ich das verstanden habe schreibt der Compiler auf Wunsch eine Checksumme ans Ende der Hex-Datei. Die kann ich verschlüsseln und dann übertragen. Stimmt der Key nicht, kann ich das nach dem Flashen erkennen.
Dazu muss ich aber nach dem Flashen im Bootloader stehen bleiben, was ich bisher für unmöglich hielt.
Aber halt, die Doku will genauestens studiert werden:

"Die Funktion UpdateFirmware kehrt niemals ins Boot zurück, wenn der Download erfolgreich war sondern startet automatisch die neue Applikation. Das kann unterbunden werden indem man das obige CallBack besetzt. "

Aha, den kleinen aber entscheidenden Satz hatte ich übersehen. In der Demo ist von einem Callback nichts zu finden, aber in der Doku steht etwas:

...
...


Aha, die "FAT_Boot_SetUsrProc" erlaubt wohl ein Flashen ohne direkte Rückkehr ins Hauptprogramm! So etwas habe ich gesucht.
Damit "könnte" ich also die Checksumme prüfen und ggf. einen neuen Anlauf starten.

Der Parameter erwartet eine Procedure, vielleicht kann mir jemand mit mehr Ahnung sagen, was diese procedure machen können muss und ob ich darin die Checksumme des gerade geschriebenen Programms prüfen kann?

Leider gibt es zu der FAT_Boot_SetUsrProc genau 0 weitere Infos.

Ich vermute sie schreibt die Datei ins Flash und danach landet man in der Procedure die man im Parameter angegeben hat? Dort könnte ich dann das gewünschte machen.
Habe ich da richtig geraten?