Frage zu Checksumme und Bootloader

  • 1
  • 2
  • Page 1 of 2
Lschreyer
Schreiberling
Avatar
Gender: n/a
Posts: 527
Registered: 02 / 2007
Subject:

Frage zu Checksumme und Bootloader

 · 
Posted: 21.01.2019 - 16:04  ·  #1
Ich habe versucht die Doku zu Flash Checksum zu begreifen, stoße da aber leider an Grenzen.

So wie ich das verstanden habe kann ich in meinem Programm durch den Import vo
from System import FlashCheck_S, FlashCheck_A;
und
define FlashChkSum = ProgEnd;

veranlassen, dass der Compiler eine Checksumme berechnet und sie ans "Ende des Flashbereichs" speichert. Soweit so gut, sobald ich im Programm dann mit CalcFlashCheck_S(); die CRC prüfe klappt das auch. Es gibt 1 zurück.

Jetzt will ich das ja gerne in meinem Bootloader machen, wo ich das Programm flashe, und danach dann die CRC prüfen will um zu sehen, ob das Flashen fehlerfrei geklappt hat.
Da komme ich nicht weiter, egal was ich versuche liefert CalcFlashCheck_A vom boot aus immer eine 2 zurück.

Wenn ich in der Main App
define FlashChkSum = ProgEnd;
definiere, was muss ich dann in der Bootapp definieren, damit die gespeicherte CRC summe aus dem Bootbereich gelesen werden kann?

In der Doku steht da auch
define FlashChkSum = (2 * BOOTRST) -2;

Das wären 2 Byte unter der obersten Flashgrenze?
Wenn ich das in der Mainapp verwenden will gibt es einen Fehler, "Identifier or factor expected"

Was ist "Progend" genau? In der Doku/Hilfe steht davon nichts.
Lschreyer
Schreiberling
Avatar
Gender: n/a
Posts: 527
Registered: 02 / 2007
Subject:

Re: Frage zu Checksumme und Bootloader

 · 
Posted: 21.01.2019 - 16:45  ·  #2
Ich habe es nun mehrfach getestet. Ein Testprogramm direkt ins Flash geladen ergibt in den letzten 2 Bytes die Checksumme $6FC9

Wenn ich exakt diese Datei als dld speichere und über den FatLoader ins Flash lade steht da am Ende des Flashes aber $2889 wenn ich AES verwende und $4008 wenn ich es ohne AES mache. Da ist es kein Wunder dass der CRC check fehlschlägt.

Was passiert da?

Die unverschlüsselte DLD zeigt im Hex Editor $6FC9 am Ende, also korrekt.
Verwurschtelt der Fatloader die crc?
Thomas.AC
Benutzer
Avatar
Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013
Subject:

Re: Frage zu Checksumme und Bootloader

 · 
Posted: 21.01.2019 - 19:28  ·  #3
Hallo,

hier verstecken sich viele Fallstricke und ich habe selber den FATLoader nur rudimentär getestet.

Soweit ich weiß ist das Ende der DLD-Datei ist nicht das Ende vom Flash. Ansonsten hättest du ein Problem, da der FAT-Loader versucht sich selbst zu überschreiben. Ich glaube Thorsten hat das herausgefunden. Ihm Gebührt die Ehre. :-) Er hat auch herausgefunden, dass ein AddApp zum Einbinden des Bootloaders bei den defines nicht benutzt werden darf, wenn eine DLD-Datei zu erstellen ist.

[Edit]
FlashCheck_A verbietet AddApp auch. Hat Joachim alias jomixl herausgefunden. Ihm Gebührt auch Ehre. :-) Dank ihm funktioniert das Flashcheck_A im Boot - hoffe ich. Und den Callback hatte ich mir gewünscht. Danke an Rolf, dass er diesen hizugefügt hat. Demo gibt es unter AVRcoAVRcoDemosXMega_FATboot

Gruß
Thomas
Lschreyer
Schreiberling
Avatar
Gender: n/a
Posts: 527
Registered: 02 / 2007
Subject:

Re: Frage zu Checksumme und Bootloader

 · 
Posted: 21.01.2019 - 20:40  ·  #4
Ich habe es gerade herausgefunden.

Ich hatte FlashchkSum auf das Ende des Flashs gesetzt. Das war falsch, es muss 2 Byte unter dem Bootbereich liegen. Beim 256a3U also auf 1FFFF *2 -2
Ich hattes auf 20FFF*2-2.

Was mich verwirrt hat ist die Tatsache, dass FlashChkSum im Fatloader dazu führt, das der Compiler auch für den Fatloader eine Checksumme berechnet, und die dann an die selbe Stelle schreibt. Liegt nun FlashchekSum im Bootbereich, wird dieser Wert natürlich nie durch die Checksumme eines neu geladen Mainapps überschrieben und das führt dann zu einem Fehler. Die Prüfroutine erzeugt eine Checksumme über den Flashbereich und prüft das dann gegen die falsche FlashChkSum. Blöd.

Man muss also zwingend aufpassen, ist eigentlich klar, dass man für die Mainapp und im Fatloader die FlashChekSum im Programmspeicher legt, unterhalb des Bootbereichs. Dann klappt es. Ich kann jetzt über den Callback nach dem Flashvorgang die Fehlercodes auslesen und die Checksumme prüfen und so sicher stellen, dass alles ok ist bevor ich die letzte Eepromstelle auf 00 setze. Puh, hat lange gedauert, aber geht jetzt sauber durch, und schnell ist das erst!

Das mit der Addapp muss ich noch testen, wäre sinnvoll.

Ich werde dann ggf. mal eine demo basteln und hier hochladen, falls das noch mal jemand braucht.
Lschreyer
Schreiberling
Avatar
Gender: n/a
Posts: 527
Registered: 02 / 2007
Subject:

Re: Frage zu Checksumme und Bootloader

 · 
Posted: 22.01.2019 - 14:22  ·  #5
Ist es möglich bei nicht vorhandener Datei auf der SD-Card einen Fehler auszugeben?
Ich habe gerade mal probiert was da passiert, leider passiert da nichts, es wird nicht in die Callbackproc gesprungen, und man kann dann also nichts mehr machen. Es wäre super wenn da normal verfahren wird und ein Fehler in BootErr stehen würde.

Da ich selbst nicht nach Dateien suchen kann ist man da ziemlich aufgeschmissen, wenn der Dateiname nicht stimmt oder die Datei schlicht fehlt.
pvs-deck
PowerUser
Avatar
Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1341
Registered: 02 / 2009
Subject:

Re: Frage zu Checksumme und Bootloader

 · 
Posted: 22.01.2019 - 14:42  ·  #6
Quote by Lschreyer

Ist es möglich bei nicht vorhandener Datei auf der SD-Card einen Fehler auszugeben?
Ich habe gerade mal probiert was da passiert, leider passiert da nichts, es wird nicht in die Callbackproc gesprungen, und man kann dann also nichts mehr machen. Es wäre super wenn da normal verfahren wird und ein Fehler in BootErr stehen würde.

Da ich selbst nicht nach Dateien suchen kann ist man da ziemlich aufgeschmissen, wenn der Dateiname nicht stimmt oder die Datei schlicht fehlt.


Hallo,

ich mache dies bereits in der MainApp "F16_FileExist()" bevor ich die Firmware-Update Funktion starte (Sprung nach boot) und Speicherstelle setzen.

Aber ich bekomme bei nicht vorhandener Datei die Fehlermeldung "bootClusterNotfound"
(siehe Bild)
Thorsten
Attachments
Keine FW
Filename: 22-01-_2019_14-41-40.png
Filesize: 645.5 KB
Title: Keine FW
Information: Keine FW
Download counter: 113
Lschreyer
Schreiberling
Avatar
Gender: n/a
Posts: 527
Registered: 02 / 2007
Subject:

Re: Frage zu Checksumme und Bootloader

 · 
Posted: 22.01.2019 - 17:01  ·  #7
Danke, ich hatte einen Fehler im Code der die Fehlerausgabe verhinderte :-(

Jetzt klappt das auch bei mir! Die Datei vorher zu suchen macht Sinn, habe ich jetzt auch so eingebaut.

Ich unterscheide jetzt zwei Dinge:

Möglichkeit 1.
Der Versuch ein neues Main zu flashen schlug fehl (Aufruf von UpdateFirmware($1234)=false, keine Karte, Datei fehlt, BootLoaderID falsch usw.)
Das gibt dann einen Booterr>0, den piepse ich aus (z.B. piep piep piep = 3), setze ein Byte im Eeprom auf $55 und ein Byte im EEprom mit dem BootErr.
Dann springe ich ins Main. Dort findet das Main das Byte auf $55 und liest die letzte BootErr aus dem EEprom und zeigt es an. Da am Flash nichts geändert wurde läuft das dann erst mal weiter.

Möglichkeit 2.
Es wurde zwar etwas geflasht, aber das ist korrupt/beschädigt/gefälscht (Die CRC Checksumme ist nicht korrekt)
Das gibt dann akustisch Alarm, leider kann ich den Dateinamen nicht ändern, sonst könnte ich dann ein Notsystem flashen damit er den Fehler anzeigen kann.
Der Dateiname ist ja leider fest. Der User hört aber deutlich, dass etwas faul ist.

Das fängt so eigentlich alle Möglichkeiten ab.
Notfalls gibt es noch einen Kontakt den man brücken kann um zwangsweise in den Bootloader zu gelangen. Für alle Fälle. Da muss der User dann eben zusehen, dass die korrekte Datei auf der Karte liegt, weil ich es ja nicht vorher abfragen kann.

Aber so klappt es super, sehr nützlich das Ganze! Ein Hoch auf Avrco :-)
Thomas.AC
Benutzer
Avatar
Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013
Subject:

Re: Frage zu Checksumme und Bootloader

 · 
Posted: 24.01.2019 - 21:44  ·  #8
Mir schwirrt da noch eine Sache im Kopf herum. Dies betrifft den Prozessorclock.

Ich hatte einmal testweise den "FAT Bootloder Xmega" im Betrieb.
Der Bootloader lief mit dem internen 32MHz clock.
Die Applikation sollte aus einem 3.072 MHz Quarz einen 30,072 MHz CPU-Clock erzeugen.

Irgendwie hatte ich damals einen falschen Clock in der Applikation. Bin der Sache nicht mehr weiter nachgegangen. Vielleicht habe ich auch einen Fehler gemacht. Daher möchte ich lediglich darauf hinweisen, dass unterschiedliche Clock defines (OSCtype) im Bootloader und Applikation ein Problem sein könnten. Ich meine, hier im Forum darüber schon einmal etwas gelesen zu haben. Kann den Beitrag leider nicht mehr finden.
  • 1
  • 2
  • Page 1 of 2
Selected quotes for multi-quoting:   0

Registered users in this topic

Currently no registered users in this section

The statistic shows who was online during the last 5 minutes. Updated every 90 seconds.
MySQL Queries: 16 · Cache Hits: 15   142   157 · Page-Gen-Time: 0.034057s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI