Codice che rovina schede

Salve scrivo qui per un problema che ho con un codice

premetto che uso l'IDE 1.8.1
due cloni di arduino uno con Atmega 328p-pu e atmega 16u2
Tutti e due vengono riconosciuti nella gestione dispositivi e nelle porte dell'IDE
Hanno sempre funzionato in altri progetti

ho scritto due cloni perchè mi è capitato la stesso problema dopo che ho caricato lo stesso codice pensando ad un problema della scheda

il problema consiste nel fatto che non posso più caricare niente (, che il led "L" resta sempre acceso e che lo sketch non funziona più

Soluzioni provate:

  • Reinstallare tutto l'IDE
  • Loop Back Test
  • Riflashato l'atmega 16u2 su un arduino avendo letto che poteva essere il problema
  • Tenere premuto il reset e rilasciarlo nel momento dell'upload

Lo sketch che ho caricato in pratica comanda un oled e un dht11

Allego il codice perchè supero i 9000 caratteri

Ringrazio per eventuali risposte

Arduino code.txt (34.3 KB)

Nella setup() SEMPRE meglio mettere come prima istruzione un bel delay(1000);
in questo modo si ha 1 secondo dopo il reset per la manovra d'emergenza

nid69ita:
Nella setup() SEMPRE meglio mettere come prima istruzione un bel delay(1000);
in questo modo si ha 1 secondo dopo il reset per la manovra d'emergenza

purtroppo non ero a conoscenza della manovra d'emergenza visto che non ho mai avuto problemi, grazie per il consiglio, lo usero in futuro

nid69ita:
in questo modo si ha 1 secondo dopo il reset per la manovra d'emergenza

Questa cosa della manovra d'emergenza l'ho sempre ritenuta una mezza leggenda metropolitana :slight_smile:
Vediamo perché, quando l'IDE deve programmare Arduino invoca avrdude, con relativa riga di comando, che provvede al trasferimento del codice sul micro, dal punto di vista di avrdude dal lato opposto c'è un programmatore hardware e come tale lo considera, questo perché il bootloader è una emulazione software di un programmatore hardware.
Quando avrdude inizia il dialogo con il micro come prima cosa apre la porta seriale e questo comporta un reset hardware di Arduino, ovvero è la stessa cosa di premere il relativo pulsante che però viene fatta in automatico, dopo aver aperto la seriale avrdude cerca di instaurare il dialogo col bootloader, ovvero l'emulazione del programmatore, se ci riesce inizia il trasferimento del codice, se non ci riesce appare il famigerato errore "stk500.......".
Dato che il micro viene resettato qualunque cosa stava facendo viene interrotta, tutti i pin vanno in stato di alta impedenza, tutti i registri e le periferiche sono portate allo stato di default, dopo pochi ms inizia l'esecuzione del codice del bootloader, che non ha nulla a che vedere con lo sketch caricato e inizializza il micro a suo uso, in particolare inizializza la porta seriale per poter comunicare col pc.
Se il bootloader inizia il dialogo con avrdude parte la procedura di trasferimento del codice macchina e la sua memorizzazione sulla flash, fase che può richiedere anche diverse decine di secondi, se non inizia il dialogo dopo poco tempo, se non mi ricordo male circa 300 ms, il bootloader termina il suo lavoro e trasferisce l'esecuzione allo sketch caricato sulla flash.
Il fatto di mettere un delay nella setup, non importa di 100 ms o 10 ore, non ha alcuna influenza nel processo che ho descritto sopra perché nel momento in cui questo delay viene eseguito il bootloader ha già terminato il suo lavoro e ritardare l'avvio del proprio codice non serve a nulla a meno che non sia una cosa desiderata per altri motivi.
Il vero motivo per cui a volte può essere necessario tenere Arduino resettato manualmente per riuscire a programmarlo è quando si "bombarda" di dati la comunicazione seriale verso il pc con un flusso costante, questo può portare a problemi di mancato svuotamento della coda in invio sul 16u2 quando si cerca di programmare Arduino, ovvero anche se il micro di Arduino è resettato il 16u2 continua ad inviare gli ultimi dati verso il pc, sono nel suo buffer, non in quello previsto da Arduino sul suo micro, e questa cosa può dare fastidio ad avrdude.
Inserire o meno un delay nel setup non cambia nulla sul riempimento del buffer del 16u2, cosa che avvviene in run time, pertanto è assolutamente inutile metterlo, anche la stessa manovra di emergenza è praticamente inutile nel 99.99% dei casi perché per arrivare alla condizione di buffer dati del 16u2 pieno con relativo problema per avrdude è una cosa che tocca mettersi veramente d'impegno per farlo, basta usare la seriale ad almeno 38400 bps per evitare il problema, solo se si usa la velocità a 9600 bps, o minore, con invio costante sulla seriale, senza soste, si arriva alla situazione che può dare problemi a avrdude.

astrobeed:
Questa cosa della manovra d'emergenza l'ho sempre ritenuta una mezza leggenda metropolitana :slight_smile:
Vediamo perché, quando l'IDE deve programmare Arduino invoca avrdude, con relativa riga di comando, che provvede al trasferimento del codice sul micro, dal punto di vista di avrdude dal lato opposto c'è un programmatore hardware e come tale lo considera, questo perché il bootloader è una emulazione software di un programmatore hardware.
Quando avrdude inizia il dialogo con il micro come prima cosa apre la porta seriale e questo comporta un reset hardware di Arduino, ovvero è la stessa cosa di premere il relativo pulsante che però viene fatta in automatico, dopo aver aperto la seriale avrdude cerca di instaurare il dialogo col bootloader, ovvero l'emulazione del programmatore, se ci riesce inizia il trasferimento del codice, se non ci riesce appare il famigerato errore "stk500.......".
Dato che il micro viene resettato qualunque cosa stava facendo viene interrotta, tutti i pin vanno in stato di alta impedenza, tutti i registri e le periferiche sono portate allo stato di default, dopo pochi ms inizia l'esecuzione del codice del bootloader, che non ha nulla a che vedere con lo sketch caricato e inizializza il micro a suo uso, in particolare inizializza la porta seriale per poter comunicare col pc.
Se il bootloader inizia il dialogo con avrdude parte la procedura di trasferimento del codice macchina e la sua memorizzazione sulla flash, fase che può richiedere anche diverse decine di secondi, se non inizia il dialogo dopo poco tempo, se non mi ricordo male circa 300 ms, il bootloader termina il suo lavoro e trasferisce l'esecuzione allo sketch caricato sulla flash.
Il fatto di mettere un delay nella setup, non importa di 100 ms o 10 ore, non ha alcuna influenza nel processo che ho descritto sopra perché nel momento in cui questo delay viene eseguito il bootloader ha già terminato il suo lavoro e ritardare l'avvio del proprio codice non serve a nulla a meno che non sia una cosa desiderata per altri motivi.
Il vero motivo per cui a volte può essere necessario tenere Arduino resettato manualmente per riuscire a programmarlo è quando si "bombarda" di dati la comunicazione seriale verso il pc con un flusso costante, questo può portare a problemi di mancato svuotamento della coda in invio sul 16u2 quando si cerca di programmare Arduino, ovvero anche se il micro di Arduino è resettato il 16u2 continua ad inviare gli ultimi dati verso il pc, sono nel suo buffer, non in quello previsto da Arduino sul suo micro, e questa cosa può dare fastidio ad avrdude.
Inserire o meno un delay nel setup non cambia nulla sul riempimento del buffer del 16u2, cosa che avvviene in run time, pertanto è assolutamente inutile metterlo, anche la stessa manovra di emergenza è praticamente inutile nel 99.99% dei casi perché per arrivare alla condizione di buffer dati del 16u2 pieno con relativo problema per avrdude è una cosa che tocca mettersi veramente d'impegno per farlo, basta usare la seriale ad almeno 38400 bps per evitare il problema, solo se si usa la velocità a 9600 bps, o minore, con invio costante sulla seriale, senza soste, si arriva alla situazione che può dare problemi a avrdude.

Grazie per la precisazione quindi il problema potrebbe essere il bootloader, ma non capisco come sia possibile visto che ho sempre caricato sketch diversi e mai avuto problemi
Si può "rovinare" il bootloader caricando uno sketch troppo pesante? visto che tiene 30906 byte (95%) dello spazio per i programmi

miky94x:
Si può "rovinare" il bootloader caricando uno sketch troppo pesante? visto che tiene 30906 byte (95%) dello spazio per i programmi

Il micro lo puoi riempire fino all'ultimo byte disponibile, non si rompe nulla. :slight_smile:
Però un conto è la flash e un conto è la ram, dato che su Arduino viene usato un compilatore c++ è possibile usare la ram dinamica e questo può portare ad un overflow della ram con conseguente crash del micro.
Il crash dovuto ad overflow della ram può essere il tuo caso, però non può fare nessun danno e, sopratutto, non esiste che non è possibile riprogrammare il micro, non è che hai un problema hardware ? p.e. alimentazione insufficiente, pin reset tenuto a zero fisso, etc.
Se premi il reset, con lo sketch caricato, il led lampeggia ?

astrobeed:
Il micro lo puoi riempire fino all'ultimo byte disponibile, non si rompe nulla. :slight_smile:
Però un conto è la flash e un conto è la ram, dato che su Arduino viene usato un compilatore c++ è possibile usare la ram dinamica e questo può portare ad un overflow della ram con conseguente crash del micro.
Il crash dovuto ad overflow della ram può essere il tuo caso, però non può fare nessun danno e, sopratutto, non esiste che non è possibile riprogrammare il micro, non è che hai un problema hardware ? p.e. alimentazione insufficiente, pin reset tenuto a zero fisso, etc.
Se premi il reset, con lo sketch caricato, il led lampeggia ?

Ho scollegato tutto da arduino, se lo attacco all'usb il led L resta acceso, se premo reset si spegne per poi riaccendersi poco ma l'upload fallisce sempre, ho provato anche con alimentazione esterna o a cambiare usb ma niente

Premendo il tasto reset il led deve lampeggiare brevemente, se non lo fa vuol dire che non c'è il bootloader dentro il micro, devi ricaricarlo.

La cosa di "rovinare il bootloader" è successa a me. È l'unica spiegazione possibile che do a quel che è successo ad un paio di cloni cinesi che ho avuto per le mani, come se i fuse fossero settati per i 256 byte di Optiboot, ma il bootloader fosse quello vecchio più grande. In questo modo, caricando uno sketch che usa quasi tutta la flash, si sovrascrive parte del bootloader, che non funzionerà più correttamente.

Non so se sia possibile ma mi è successo su almeno 3 schede uguali e, ripeto, non ho altre spiegazioni. Avevo una 4a scheda uguale ma l'ho data via, non saprei come fare altre verifiche.

Comunque in questo caso basta un programmatore ISP (o un altro Arduino) e si ripristinano il bootloader ed i fuse corretti.

SukkoPera:
La cosa di "rovinare il bootloader" è successa a me. È l'unica spiegazione possibile che do a quel che è successo ad un paio di cloni cinesi che ho avuto per le mani, come se i fuse fossero settati per i 256 byte di Optiboot, ma il bootloader fosse quello vecchio più grande. In questo modo, caricando uno sketch che usa quasi tutta la flash, si sovrascrive parte del bootloader, che non funzionerà più correttamente.

Non so se sia possibile ma mi è successo su almeno 3 schede uguali e, ripeto, non ho altre spiegazioni. Avevo una 4a scheda uguale ma l'ho data via, non saprei come fare altre verifiche.

Comunque in questo caso basta un programmatore ISP (o un altro Arduino) e si ripristinano il bootloader ed i fuse corretti.

Ho provato mettendo l' AVRISP MKII sul atmega 16u2 con Flip, installato i driver, poi collegato arduino così:
ICSP1 MISO2.Pin.1 - ICSP MISO.Pin.1
ICSP1 SCK2.Pin.3 - ICSP SCK.Pin.3
ICSP1 MOSI2.Pin.4 - ICSP MOSI.Pin.4
JP2 PB4.Pin.1 - ICSP RESET.Pin.5

Quando lo connetto con l'usb i led rx e tx si illuminano per due volte e viene trovato nella gestione dei dispositivi

da qui dentro ad atmel studio apro il programmatore, inserisco l'ATmega328P come dispositivo, interfaccia isp, isp clock a 16.1khz e funziona tutto, riesco a leggere tutti i parametri che voglio ma quando scrivo il bootloader mettendo l'optiboot mi dice:

Timestamp: 2017-03-24 14:06:56.384
Severity: ERROR
ComponentId: 20100
StatusCode: 1
ModuleName: TCF command: Modules:writeToMemory failed.
ispReadMem: Unexpected response received: Got 0xff, expected 0x14.

i fuse sono:
extended 0xFD
high 0xDA
low 0xFF

Ma perché sul 16U2? L'Optiboot devi caricarlo sul 328...

SukkoPera:
Ma perché sul 16U2? L'Optiboot devi caricarlo sul 328...

Infatti ho scritto:

inserisco l'ATmega328P come dispositivo, interfaccia isp, isp clock a 16.1khz e funziona tutto, riesco a leggere tutti i parametri che voglio ma quando scrivo il bootloader mettendo l'optiboot

Sul 16U2 ci metto solo AVRISP MKII :smiley: per poter caricare il bootloader

Continuo a non capire. Non serve fare niente sul 16U2.

>miky94x: Il 16U2 ha SOLO la funzione di interfacciare la porta USB con la seriale del ATmega328P quindi ... NON devi assolutamente caricarci nulla (... se non il suo FW per svolgere tale funzione nel caso non funzionasse più il collegamento USB).

Il Bootloader è sul ATmega328P e quindi devi usare il normale connettore ICSP che si trova sul lato opposto della scheda rispetto al connettore USB !

Guglielmo

gpb01:
>miky94x: Il 16U2 ha SOLO la funzione di interfacciare la porta USB con la seriale del ATmega328P quindi ... NON devi assolutamente caricarci nulla (... se non il suo FW per svolgere tale funzione nel caso non funzionasse più il collegamento USB).

Il Bootloader è sul ATmega328P e quindi devi usare il normale connettore ICSP che si trova sul lato opposto della scheda rispetto al connettore USB !

Guglielmo

Vi posto il link che ho seguito per farvi capire perchè secondo me non ci capiamo :smiley: :smiley: :smiley:
Flash bootloader without a programmer

Ho capito; viene messo un Firmware sul ATmega16U2 per renderlo un programmatore ICSP per poi programmare in modo ICSP il ATmega328.
Per fare questo serve un altro programmatore ICSP. A quel punto usi il programmatore ICSP direttamente per programmare il ATmega328.
Per far funzionare il Atmega16U2 come adattatore USB seriale comunque devi dopo rimettere il Firmware precedente.

Mi sembra un giro complicato a 3 step al posto di farlo in 1 step.

Ciao Uwe

... infatti, avendo un programmatore, mi sembra un emerita BOJATA !

Se hai un programmatore ICSP usa quello sul ATmega328P e basta ... o ... NON lo hai ? ? ? :o

Guglielmo

gpb01:
... infatti, avendo un programmatore, mi sembra un emerita BOJATA !

Se hai un programmatore ICSP usa quello sul ATmega328P e basta ... o ... NON lo hai ? ? ? :o

Guglielmo

Il problema è che non c'è l'ho, l'ho ordinato ma non mi è ancora arrivato e intanto ho cercato altre soluzioni :smiley:
Alla fine non era tutto questo casino da capire :D, però non riesco a programmarlo e mi da quell'errore

uwefed:
Ho capito; viene messo un Firmware sul ATmega16U2 per renderlo un programmatore ICSP per poi programmare in modo ICSP il ATmega328.
Per fare questo serve un altro programmatore ICSP. A quel punto usi il programmatore ICSP direttamente per programmare il ATmega328.
Per far funzionare il Atmega16U2 come adattatore USB seriale comunque devi dopo rimettere il Firmware precedente.

Mi sembra un giro complicato a 3 step al posto di farlo in 1 step.

Ciao Uwe

Si dopo avrei rimesso il suo firmware originale tranquillamente, ho fatto il giro lungo non avendo un programmatore ICPS