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
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
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
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.
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.
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
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:
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 per poter caricare il bootloader
>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 !
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 !
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.
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
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
per poter caricare il bootloader