closed

Loginbox

Please enter your username and password into the following fields to log in.


  • Username:
  • Password:
  •  
  • Auto log in on every visit.


  •  

Fehler beim FAT Bootloader



Lschreyer offline
Benutzer
Avatar
Gender: n/a
Location: n/a 
Age:
Posts: 427
Registered: 02 / 2007
Private message
Subject: Fehler beim FAT Bootloader  -  Posted: 19.01.2019 - 12:25   -  
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

Code

//  FAT_BootMode     = aes;       // plain or AES
//  FAT_BootFile     = 'filename';    // an AES file

  FAT_BootMode     = plain;       // plain or AES
  FAT_BootFile     = 'filename';      // a plain file


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.
go down go up
pvs-deck offline
Schreiberling
Avatar
Gender: male
Location: GERMANY 
Age: 47
Posts: 965
Registered: 02 / 2009
Homepage Private message
Subject: Re: Fehler beim FAT Bootloader  -  Posted: 20.01.2019 - 07:47   -  
Hallo Lschreyer,

genau dafür gibt es die Checksum Funktionen. Diese kannst Du dann schon im MainApp prüfen. Da steht auch etwas im Programmer Manual.

Ich denke bei einer Fehlerhaften AES wird es schwer. Ich glaube nicht, dass es da eine Überprüfung einer Checksumme gibt. Es wird wahrscheinlich einfach alles was Du reinschickst mit dem Schlüssel entschlüsselt und fertig.

Ich glaube Dein Weg führt nur über das Thema Checksumme.

Thorsten
---------------------------------------------------------
Nichts ist unmöglich in der Elektronik und der Software, die Grenzen
setzt nur das Budget, Zeit und der Entwickler! ( P V S - D E C K )
This post has been edited 1-times. Last edit: 20.01.2019 - 07:49 by pvs-deck.
go down go up
Lschreyer offline
Benutzer
Avatar
Gender: n/a
Location: n/a 
Age:
Posts: 427
Registered: 02 / 2007
Private message
Subject: Re: Fehler beim FAT Bootloader  -  Posted: 21.01.2019 - 10:36   -  
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:

...
...
Code
procedure FAT_Boot_SetUsrProc(p : procedure); // Set the CallBack address
// This reads the UpdateFile and flashes it into the application area.
function UpdateFirmware(BootID : word) : boolean;


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?
This post has been edited 1-times. Last edit: 21.01.2019 - 10:36 by Lschreyer.
go down go up
 


Registered users in this topic
Currently no registered users in this section

Delete cookies of this forum  •  FAQ / Help  •  Team page  •  Imprint   |  Local time: 21.02.2019 - 03:16