Man muss nicht unbedingt wissen, was die LEDs bedeuten. Es kann nur hilfreich sein, wenn man ein Problem hat.
S32 hat wie JLog vier LEDs: rot, orange, grün, blau.
Die Software von S32 besteht wie bei JLog aus zwei Teilen, die nie gleichzeitig ausgeführt werden: Bootloader, Applikation.
Beide Softwareteile verwenden die LEDs, um dem Anwender etwas zu signalisieren. Somit muss man die LEDs getrennt betrachten und dabei auch im Übergang von Bootloader zu Applikation beschreiben.
Bootloader
rot: Die rote LED signalisiert Schreiben in Pages des Flash Speichers des S32, was nur stattfindet beim Update der Firmware.
grün: S32 ist verbunden via USB.
orange: leuchtet für jeden Datentransfer Terminal–S32 via USB.
blau: Datentransfer auf dem Datenbus, wenn S32 als Gateway zwischen Terminal und einem BID dient.
Die beiden Programme, Bootloader und Applikation, leben zeitlich in unterschiedlichen Universen. Da sie nie gleichzeitig laufen, können sie zunächst nicht miteinander kommunizieren. Sie tun es aber doch vermittels eines “toten Briefkastens”. Der Bootloader ist das Programm, was mit dem Terminal kommuniziert, Die Applikation liest dann nur das Setup aus dem gemeinsamen (BL+APP) Speicher und führt es aus.
Steckt man S32 an USB, bekommt er daher Betriebsspannung und startet wie immer zuerst den Bootloader. Der guckt nach, ob es einen USB Connect gibt. Wenn ja, geht er in seine Routine zur Kommunikation mit dem Terminal, wenn nein, startet er die Applikation. Nun hängt alles davon ab, wie schnell der USB Host einen elektrischen Connect erkennt und einen logischen Connect zu S32 herstellt. Davon hängt ab, ob S32 zu diesem Zeitpunkt noch im Bootloader ist, oder bereits die Applikation ausgeführt wird. (Im USB Host sind dessen Ports jeweils einem USB Hub zugeordnet. Hat man an einem Port desselben Hub z.B. bereits einen USB SD Card Reader, dann erkennt der Host auf einem anderen Port desselben Hub ganz schnell den S32 als connected. Wenn nicht, reagiert der Host langsamer, – S32 ist bereits in der Applikation).
Die Applikation in S32 erkennt daher auch, wenn ein USB Connect erfolgte. Sie steckt eine Nachricht an den Bootloader in den toten Briefkasten und resettet den S32, der daraufhin in den Bootloader startet. Der Bootloader schaut nicht nur nach einem tatsächlichen USB Connect, er sieht auch die Nachricht im Briefkasten, dass USB Connect gewollt ist. Dem folgt er. — Bedingt dadurch, dass S32 bereits die Applikation laufen gehabt haben kann, sieht man auch unterschiedliches LED-Kino, nämlich erst das der Applikation, dann oben beschriebenes des Bootloaders am USB.
Es gibt einen weiteren Typ Nachricht im toten Briefkasten, – Applikation an Bootloader: Die heißt, “hey, ich lebe”. Es könnte ja sein, dass eine nicht lauffähige Applikation beim Update geflasht wurde. Dann wäre es schlecht, wenn der Bootloader sie immer sofort starten würde. Findet der Bootloader beim Powerup des S32 keine AmLeben-Nachricht von der Applikation, dann geht er von sich aus auf USB, wartet auf einen Connect, damit das Terminal es richten kann.
Er hängt aber nicht ewig auf USB wartend ab, sondern nur für ein paar Sekunden, – danach startet er trotzdem die Applikation, die kein Lebenszeichen hinterließ. Sprich, im Fall der Fälle hat man immer ein hinreichendes Fenster, um USB Connect zum Terminal zu bekommen, das die Applikation richten kann.
Das bewirkt einen weiteren an den LEDs sichtbaren Effekt: Solange der Bootloader wegen fehlenden Lebenszeiches von der Applikation auf USB Connect wartet, lässt er die orange LED blinken.
Wenn ich S32 an USB steckte, USB versorgte ihn mit Spannung, dann abstecke und mit RC-Spannung starte, dann war die Applikation beim letzten Mal nicht gelaufen. Das sieht man daran, dass beim ersten Start nach USB-Verbindung erst die orange LED ein Weile blinkt, bevor die Applikation startet, – während jeder folgende Start das nicht mehr tut, nach der Bootloader-Schutzroutine für den NAND (s.u.) sofort die Applikation startet.
Applikation
Ein ARM Prozessor hat keinen EEPROM, stattdessen nur einen NAND Flash, wie beispielsweise in einer SD-Karte oder einem USB-Memory-Stick (oder einer SSD). In einer NAND-Zelle kann man ein Bit nur von logisch Eins auf Null ändern, nicht umgekehrt, man muss erst die Zelle löschen, um in einem Bit Null zu Eins werden zu lassen. Außerdem ist NAND seitenweise (page) organisiert, die Page Size ist gerätespezifisch und von der Position im Adressierungsbereich von dessen NAND abhängig. Man ist auch gehalten, etwas gegen “Wear Out” (Abnutzung) zu tun, nicht immer auf dieselben Zellen zu schreiben. SD-Karten, Memory Sticks, SSDs und eMMCs haben dafür einen Controller, sodass man die NAND (es gibt auch NOR) Zellen als logisches Array betrachten kann, In einem Prozessor muss man das aber “barfuß” tun, per Software. So ist es im S32 für den Speicherbereich, in dem das Setup landet.
Es gibt aber auch noch ganz spezifische Zellen im Speicher, die S32 wie den o.g. “virtuellen EEPROM” frühzeitig nach Powerup beschreiben muss.
Wie man einen NAND erfolgreich beschreibt, ohne seinen Inhalt ungewollt zu zerstören (immer gleich eine ganze Page!), hängt vor allem von der Spannung ab, von der man annimmt, dass sie den NAND im Augenblick des Beschreibens versorgt. Man hat das vor schreibendem Benutzen des NAND einzustellen.
Nun schließt sich der Kreis: Im Modellbau kann man von allem ausgehen, vor allem von Irrsinn seitens der Betriebsspannung für S32, – und damit für seinen NAND im Prozessor. Spannung kommt aus dem BEC eines ESC, Antiblitz nicht vorhanden oder funktioniert nicht, User erschrickt, – und schon haben wir die schönsten Betriebsspannungswackler.
Im Bootloader läuft daher nach POR (Power On Reset) ein ziemlich komplexer Vorgang ab, um den NAND zu schützen, aber noch rechtzeitig das notwendige Schreiben in ihn (siehe “toter Briefkasten”) durchführen zu können. Komplex wird es dadurch, dass man gleichzeitig im zeitlichen Wettbewerb mit dem USB Connect zum Host stehen könnte, der just-in-time bedient werden will, sonst gibt er auf. Während dieser Zeit sieht man die vier LEDs rot bis blau in aufsteigender Folge an gehen, dann absteigend wieder aus. Das ist immer noch der Bootloader, das LED-Kino der Applikation folgt erst danach:
Setup-unabhängig tut die Applikation nur ein’s mit den LEDs: Sie macht sie alle gleichzeitig, rot|orange|grün|blau für eine halbe Sekunde an, dann wieder aus. Heißt: Hallo, hier die Applikation, bin eben gestartet.
Was jetzt folgt, hängt vom Setup ab, – vornehmlich vom gewählten ESC (nur in einem Fall von der Telemetrie: Futaba), vom LogStop und vom Eintreten einer Alarmbedingung, sowie von Aktivität auf dem Datenbus. Zu Futaba, betrifft rot und blau, lese man in obigem Link. Ansonsten:
rot: Sollte nie an gehen, bedeutet fatalen Fehler seitens des Dateisystems auf der SD-Karte.
orange: Blitzt für jeden Schreibvorgang auf der SD. Dauerleuchten heißt, dass eine der konfigurierten Alarmschwellen einen Alarm auslöste.
grün: signalisiert Datenverkehr mit dem ESC
blau: signalisiert Verkehr mit einem Gerät auf dem Datenbus
.
Durch diese Liebesbriefe zwischen Applikation und Bootloader ist es nicht erforderlich, dass S32 stromlos war, bevor man USB ansteckt. Er erkennt USB immer und beginnt immer, mit dem Terminal zu reden.
