README-hwsig -- Hardware Signatur Ein Programm darf nur auf der passenden Hardware laufen. Jede kleine Änderung des Layouts oder der Bestückung kann für die Anwendung üble Folgen haben. Falls Benutzer selbst Updates einspielen, muss man damit rechnen, dass die Firmware für das falsche Gerät geladen wird. Wenn dann garnichts funktioniert, hat man Glück gehabt... Das Programm muss also selbst prüfen können, ob es auf der richtigen Hardware läuft. Es kann aber kleine Unterschiede nicht zuverlässig feststellen, z.B. wenn im Layout nur zwei Pins vertauscht wurden oder ein Widerstandswert geändert wurde. Eine echte Hardware-Signatur ist also nicht praktikabel. Das nächstbeste ist eine Signatur, die bei der ersten Inbetriebnahme der Platine in den Flashspeicher geschrieben wird. Bei jeder Änderung der Hardware, Bestückung oder Layout, ändert sich diese Information und muss im Flash gelöscht und neu programmiert werden. Bei einem Firmware-Update darf sie nicht gelöscht werden. Sachnummer und Rev. der unbestückten Platine sind zwar eindeutig, weil aus Kupfer, aber nicht ausreichend, weil es je nach Anwendung Bestückungsvarianten geben kann und davon jeweils mehrere Revisionen. Außerdem können auf einer Platine mehrere uC drauf sein, die jeweils eine eigene Firmware brauchen. Es können aber auch viele mit gleicher Funktion, also gleicher Firmware sein. Umgekehrt kann die Firmware für verschiedene Geräte(varianten) gut sein, u.U. sogar für verschiedene Platinen. Auf jeden Fall muss eine neue Firmware auch auf älterer Hardware laufen, aber nicht unbedingt auf der allerältesten. Eine Universal-Firmware muss auslesen können, auf welchem Gerät sie läuft. Die Signatur muss also die Sachnummer des Gerätes, die Sachnummer und Revision der Platine und den Stand der Bestückung enthalten. Platinen mit mehreren programmierbaren Chips brauchen zusätzlich noch deren Reference Designator. Die Sachnummern der Leiterplatte t, b und m sind für die Signatur nicht nötig; sie könnten als Kommentar ins Flash geschrieben werden. Wenn eine Platine ein eigenes Typenschild hat, also eine lesbare Sachnummer, gilt für die Signatur trotzdem die des kompletten Gerätes, weil die Platine in Geräten für unterschiedliche Anwendungen verbaut sein kann. In der Regel sollte ein Gerät mit steckbaren Platinen eine eigene Gerätekennung haben, z.B. ein 1-Wire-EEPROM. Die hwid soll nicht so lang werden, also werden nicht alle möglichen Kombinationen kodiert; stattdessen nummeriert man nur die tatsächlich gebauten fortlaufend. Diese Nummer muss pro Platine in einer Liste bei neben den Layout-Daten verwaltet werden. Eine Art Sachnummer geht nicht, Sachnummern sollen sich nie ändern. Eine Seriennummer kommt garnicht in Frage, die darf sich nun wirklich nie ändern. Nebenbei: die Seriennummer des Gerätes darf nicht auf der Platine stehen, weil die Platine auch (gerade) auf der Baustelle in ein anderes Gerät eingebaut wird. Layout Rev.- mit der originalen Bestückung bekommt die 0, bei jeder Änderung oder neuen Variante wird hochgezählt. Die 1 kann also aus 3 Gründen vergeben werden: - ein Widerstandswert wurde geändert, Leiterbahn aufgetrennt... - Layout Rev.A - die Platine wird für ein weiteres Gerät verwendet (egal, ob sich dafür die Bestückung ändert oder nicht) Also besteht die hwid aus - dieser laufenden Nummer (vid) - der Sachnummer der unbestückten Platine (pcb, dash) - dem Reference Designator des Controllers (part) (eine Platine mit mehr als einem Controller hat mehrere hwid) Das Programm, mit dem die Firmware ins Flash geschrieben wird, sollte diese Hardware-Signatur auslesen und mit einer Liste in der s19-Datei vergleichen. Das spart dem Benutzer den Frust einer Verwechselung. Mit einem fremden Programm hat man die Möglichkeit nicht, aber wenn kein anderer Fehler passiert, kann die Kompatibilität immernoch zur Laufzeit geprüft werden. Allerdings könnte ein fremdes Programm das Flash komplett löschen. Dann ist eine neue Erstinbetriebnahme die einfachste Lösung. Auf der Baustelle müsste man erstmal den richtigen Bootloader flashen (der enthält diese Info), dabei ist aber keinerlei Überprüfung möglich. Dazu müsste man das Gerät auseinander bauen, den Aufkleber mit der hwid finden und sich die passende s19-Datei schicken lassen. Im zweiten Schritt müsste die eigentliche Firmware geladen werden. Dann kann zur Laufzeit verglichen werden, ob beide zusammenpassen, aber immer noch nicht, ob sie zur Hardware passen! Oder eben: ein gelöschter Bootloader muss im Werk repariert werden. Leider kann man auch da nicht sicher sein, dass die richtige Datei geflasht wird. Eine zuverlässige automatische Hardware-Erkennung ist nur mit einem gründlichen In-Circuit-Test möglich; den Aufwand hat man noch nie getrieben. Der Vergleich der Hardware-Version mit der Liste muss so früh wie möglich passieren (jeder Maschinenbefehl und jedes Register könnte unterschiedlich sein), also am Anfang von crt0.c vom Bootloader. Oder in crt0.c von syslib, falls es keinen Bootloader gibt. Die Tasks werden dann von find_image() geprüft, da ist es nur ein Test mehr. Genauso könnte syslib vom find_image() im Bootloader geprüft werden. Naheliegend wäre ein Schreibschutz für die hwid, aber der hilft nur bei Updates. Bei Hardware-Änderungen stört er und wenn man nicht gut aufpasst, ist die Platine Schrott (wenigstens der Chip). Wenn man OTP-Bytes benutzt, hat man immerhin 31 Versuche, mit dem normalen Flash-Schreibschutz u.U. nur einen, weil man dafür die Option Bytes schreiben muss. Damit kann man den Chip auf mindestens zwei Arten schrotten. Wobei STM sogar an einen Schutz gegen Stromausfall gedacht hat, leider ohne Erfolg: Caution: Upon an option byte programming failure (for any reason, such as loss of power or a reset during the option byte change sequence), the mismatch values of the option bytes are loaded after reset. Those mismatch values force a secure configuration that might permanently lock the device. Traditionell gab es oft einen Aufkleber mit der Firmware-Version. Das geht nicht mehr, wenn man Updates auf der Baustelle erlaubt. Der UART-Bootloader des STM32L412K erlaubt es, die OTP-Bytes zu lesen.