Der bisherige Bootloader SBL-I (SecureBootLoader) nahm Updates zum Flashen des ROM des Loggers seriell, man brauchte ein passendes (TTL-Pegel) FTDI dazu, einen USB-zu-seriell-Konverter.
Nun gibt es den SBL-II. Dieser führt ein Update automatisch durch (Flashen des ROMs des Loggers), wenn er beim Starten eine passende Datei im Wurzelverzeichnis des Dateisystems der SD-Karte findet. Das Update benötigt etwa 2..3 Sekunden, währenddessen zwinkert die rechte, i.Allg. blaue LED.
Die Update-Datei ist individuell je JLog, also je “Seriennummer”, und wird von mir erzeugt und per Email zugeschickt.
Damit das funktionieren kann, muss der betreffende Logger aber erst den neuen Bootloader SBL-II bekommen. Das kann nur ich machen, es geht per ISP-Programmer und benötigt spezielle Software und die “Datenbank” hier, weil ja die Updatedateien verschlüsselt sind.
Der Programmer geht an die 4 freien Lötaugen an der anderen Stirnseite des Loggers, und zwar von der Oberseite (Bestückungsseite) aus. Es muss dazu nicht gelötet werden. Die andere Seite wird nur zur Stromversorgung während des Programmierens des Bootloaders benötigt. Dadurch ist es im Weiteren kein Hindernis, sollte der betreffende Logger keine 6-polige Stiftleiste dran haben, also nur ein Servokabel (nebst Diode).
————————————————————
Wie funktioniert das, etwas im Detail betrachtet?
Zunächst: JLog beherbergt zwei Programme, den Bootloader und die eigentliche Applikation, die den Logger ausmacht. Beide Programme befinden sich in voneinander getrennten Sektionen des Speichers. Der Bootloader ist so was wie das (ROM-residente) BIOS eines PCs. Er wird nach Reset oder Power-Up zuerst gestartet, – wird er nicht zu einem Update bemüht, startet er die Applikation. Beide Bootloader, der bisherige SBL-I und der neue SBL-II, bekommen ein Update verschlüsselt, sie entschlüsseln das vor dem “Brennen” in den Speicher (ROM) des Loggers. Das Chiffrat ist individuell je Logger, also je Seriennummer.
SBL-II enthält eine rudimentäre Unterstützung für Dateisysteme vom Typ FAT16 und FAT12, ohne und mit MBR. Er sucht bei jedem Start zunächst nach einer Datei der passenden Länge (32720 Bytes == 32kBytes). Der Dateiname ist dabei egal, er lautet aber üblicherweise so wie “4C5872DF.bin”, Seriennummer.bin. Diese Datei ist das verschlüsselte Abbild des Speichers (ROM). Durch die Änderung zwischen 2.7 und 2.71 hat die Datei wie der ROM einen Trailer mit Informationen für den Bootloader. Hat die Datei die richtige Länge, wird diese Information gelesen. Zunächst gibt es eine Device-ID, die zum Gerätetyp passen muss. Alle momentanen JLog haben dieselbe Device-ID. Weitere Information ist das Software-Release der Applikation, im Moment 2.71 oder 2.71S. Nur, wenn das im ROM des Loggers befindliche Programm ein anderes Release hat als das in der Updatedatei, wird das Update gestartet. Der Bootloader ist so eingestellt, dass er auch Downgrades unterstützt, er flasht also nicht nur höhere Versionen, sondern grundsätzlich immer unterschiedliche. Nun wird noch geprüft, ob mit einem zur SN dieses JLog passenden Schlüssel verschlüsselt wurde.
Nach dem Flashen des ROM überprüft der Bootloader, ob das CRC (Cyclic Redundancy Check – Checksumme zum Prüfen der Integrität der Daten) OK ist. Ist das nicht der Fall, wird die Release-Bezeichnung im ROM gelöscht, und der Logger verbleibt solange im Bootloader, bis eine passende Updatedatei mit gutem CRC geflasht werden konnte.
Nochmal zusammengefasst, – automatisch geflasht (beim Start) wird, wenn,
1. die Datei sich im Wurzelverzeichnis befindet, (Dateiname egal)
2. sie die richtige Länge von 32720 Bytes hat,
3. sie für die richtige Device-ID (Hardware) ist,
4. sie für die richtige SN verschlüsselt ist,
5. das enthaltene Release der Applikation ein anderes ist als das, was sich gegenwärtig im ROM (Speicher) des Loggers befindet.
6. Die Checksumme (CRC) der Daten im ROM muss nach dem Flashen stimmen, ansonsten wird der Flash als ungeschehen markiert. (Nur bei den 4 “Early Birds”, den SBL-II von thomas1130, Franz, Joscha und Benedikt ist das noch nicht so. Sollte in deren Version der absolut unwahrscheinliche Fall eintreten, dass ein CRC-Fehler auftrat, muss zum automatischen Reflash eine andere Release-Nummer in der Updatedatei angeboten werden.)
Die erste als passend gefundene Datei im Wurzelverzeichnis (Root) wird geflasht. Danach startet sofort die Applikation.
.
Durch Fehlhandlungen kann kein Logger dauerhaft außer Betrieb gesetzt werden. Man braucht nur eine passende Updatedatei, dann heilt er sich selbst.
Das bisherige Updateverfahren mit SBL-I, also mit FTDI, wird weiterhin unterstützt von meiner Seite.
—
Danke unbekanntermaßen an Stefan Seegel und Holger von http://www.mikrocontroller.net
Tom
5. das enthaltene Release der Applikation ein anderes ist als das, was sich gegenwärtig im ROM (Speicher) des Loggers befindet.
