Cari amici, l'errore del titolo del topic è quello che ci ha sempre fatto pensare che Arduino MEGA 2560 fosse rotto quando, in seguito a qualche problema, abbiamo consigliato all'utente di usare la tecnica ISP per ricaricare il bootloader sul micro, e la procedura non è andata a buon fine fornendo appunto questo errore. Ho alcune informazioni interessanti e mi piacerebbe che si potesse finalmente arrivare ad una soluzione per la semplice ragione che il microcontrollore certamente non è difettoso, quindi coinvolgo chiunque voglia dare una mano con qualche idea, visto che ora sono in condizioni di fare prove.
La novità è questa: stasera sono finalmente riuscito a realizzare il PCB per la programmazione stand-alone dei micro 1280-2560, disponendo ora dello zoccolo per smd a 100 pin (grazie a Etem!), ma per questo aggiornerò il Topic aperto tempo fa. Premetto che ho certezza che il mio PCB funzioni senza problemi.
Ho provato a caricare il bootloader (Arduino 2009 con ISP dell'IDE 1.0.1 originale e con/senza aggiornamento toolchain 4.5.1) su un ATmega2560 nuovo, l'operazione va avanti regolarmente per circa 2-3 minuti, ma ad un certo punto si ferma ed esce l'errore suddetto; la toolchain aggiornata non risolve la cosa.
Allora ho provato a caricare direttamente degli sketch con l'opzione tipica ISP e tutto funziona regolarmente; quindi il problema non sembra dipendere dalla tecnica ISP e certamente non dipende dal micro.
Ho provato ad usare Arduino MEGA ADK come programmatore ma ho un problema: con IDE 1.0.1 non riesco a caricare nessuno sketch sulla board e quindi nemmeno ArduinoISP (aspetto suggerimenti per risolvere....)
Infine ho provato Arduino MEGA ADK con IDE 0022 e ArduinoISP (sia originale che quello di Leo), ho dovuto mettere il condensatore sul reset per superare il tipico vecchio errore, la procedura parte ma dopo lo stesso tempo dà sempre il solito errore.
Per il momento non ho altri elementi e nemmeno un neurone a posto per fare/dire altro, quindi chiudo e vado a casa, ci sentiamo tra poco, se avete idee. Grazie
Un importante aggiornamento (non sono tornato a casa 
).
Ho rifatto l'operazione con Arduino 2009 programmatore, IDE 1.0.1 con ArduinoISP originale, stesso problema, ma attivando la modalità verbose, mi pare di capire che il bootloader venga caricato tutto, solo che viene riscontrato un errore nell'ultima verifica. Pensando che fosse così ho collegato un convertitore USB-Seriale al micro e sono riuscito a caricare regolarmente gli sketch via seriale, quindi il bootloader c'è e funziona pure!
Poiché nelle preferenze c'è la possibilità di disattivare la verifica dopo la compilazione ho provato questa opzione ma non gliene frega niente, però ribadisco che continuo a caricare regolarmente via seriale.
Quindi i miei dubbi sono i seguenti:
1 - come funziona la verifica e quali sono i "componenti" hw/sw interessati?
2 - è possibile che si tratti di un banale errore nel programma che effettua la verifica o questa avviene rigorosamente e senza possibilità di errore in base al contenuto che deve avere il micro dopo il caricamento del bootloader?
Per chi volesse fare un'analisi avendone le competenze (io non le ho...) allego il verbose dell'operazione: esce tutto di colpo a fine operazione.
Prova del 9: Visto funzionare il blink caricato via seriale ho ricaricato il bootloader, il blink viene cancellato, quindi tutto il comportamento è assolutamente normale, eccetto l'errore. Davvero non so aggiungere altro.
A questo punto dico a tutti gli amici del Forum che hanno lamentato questo problema di farsi sentire su questo Topic per fare ulteriori prove.
Spero domani di trovare vostri contributi.
verbose_compilazione.txt (2.04 MB)
L'errore è già dal primo byte e il fatto che dice "0xff != 0x0d" mi fa tanto pensare al fuse per la protezione della flash, solo area bootloader, attivo, infatti in questo caso la lettura è sempre 0xff.
Tocca dare una controllata a come sono settati i fuse sulla board della Mega2560.
Guardati adesso i lock fuse forniti ad AvrDude, 0x3f, sono disabilitati quindi non può essere questo il problema, però c'è una cosa strana, l'address da cui inizia la verifica è 0x1E000, però il primo address del bootloader (4k) deve essere 0x1F000.
Se Avrdude inizia a leggere da 0x1E000 è normale che trova 0xff visto che quella è una locazione in fondo alla flash per il programma, dato che è stata cancellata ha proprio il valore 0xff.
Piccola nota tecnica, sul 2560 la flash è divisa in due blocchi da 128k, che è la causa del famigerato limite dei 128k (64 kword) se non si usa la toolchain Atmel, il program counter è da 17 bit quindi al massimo può indirizzare 128k consecutivi, ecco perché il bootloader si trova nello spazio al limite dei 128k e non al limite dei 256k.
Grazie Astro, sui fuse ero tranquillo, ma considera che io sto lavorando su un micro vergine (o meglio lo era alla prima prova), ho solo notato la comunanza dell'errore rispetto a quello ottenuto da chi ha cercato di ricaricare il bl disponendo di una MEGA (target) e di un'altra board come programmatore.
Secondo come dici, essendo quell'area di memoria vuote ovvio che non può che trovare ff in quell'indirizzo, quindi è il programma di verifica che sbaglia ad aspettarsi 0d.
Come detto se caricol il bl la flash viene cancellata (infatti sparisce il classico blink) ma poi riesco a programmarla via seriale, segno che, correggimi se sbaglio, il bl sta funzionando regolarmente.
Però non riesco a comprendere la causa dell'errore, se sapessi che posso semplicemente ignorarlo nessun problema, ma se ciò significa potenziali problemi questo è un guaio. Puoi dirmi qualcosa in più?
Considera che ho fatto le prove anche con l'aggiornamento toolchain 4.5.1, sia 002 che 1.0.1 ma senza che cambiasse nulla.
Grazie
Se è come penso io, ovvero un errore nell'address di inizio utilizzato per la verifica, puoi tranquillamente ignorare la cosa, se la causa è un altra allora potrebbero esserci eventuali problemi che potrebbero creare malfunzionamenti in certe condizioni.
Adesso non ho tempo per farlo, però tocca dare una controllata al file .hex per la programmazione e verificare i reali address utilizzati e cosa vi viene realmente scritto.
Quello che posso provare a fare tra poco è scrivere il bootloader sulla mia mega, tanto devo aggiornarlo perché è una r1, con l'AVRISP MKII e vedere se c'è lo stesso problema oppure no.
ok, grazie, mi basta questo, so che sei strampicciato, magari l'altra verifica te la chiederò un po' più avanti. 
A questo punto sarebbe utile che si facesse avanti qualcuno di quegli utenti che hanno avuto il problema direttamente sulla MEGA per fare qualche altra prova; se non ricordo male qualcuno diceva che poi riusciva a caricare via seriale ma poi aveva un problema di altro genere, devo fare una ricerca sul Forum, si tratta di 2-3 casi in questi ultimi 2-3 mesi.
Ho fatto al volo il test con l'AVRIPS MKII e AvrStudio 4, la programmazione e la verifica vanno tutte e due a buon fine, il che esclude a priori un qualunque problema legato al file .hex, ho utilizzato quello allegato al IDE 1.0.5.
Ho anche provato a caricare il file del bootloader nell'emulatore di AvrStudio per vedere come è distribuito sulla flash, ti confermo che parte da 0x1F000 e che da 0x1E000 fino a 0x1EFFF ci sono tutti 0xff, il che spiega come mia la verifica fallisce.
Ora c'è solo da capire come mai Avrdude parte da un address posto 4k sotto quello reale di inizio del bootloader.
Edit:
Oltre al classico Blink ho provato anche a caricarci sopra il software per la stampante 3D (RepRap) che occupa 105k, il tutto funziona perfettamente.
Ho chiesto alla Rivista come fanno col TDGin, visto che usano il bootolader della MEGA, mi hanno confermato che hanno lo stesso errore ma che è un problema noto; data la mia lentezza traduttiva mi riservo di guardare dopo questo Topic per capire se hanno anche una causa ed una soluzione, altrimenti comunque sono a posto, sul TiDiGino, come ricorderai, fu necessario l'aggiornamento toolchain a motivo di quei programmi enormi che vi caricavano su. Ora tu mi confermi 105k di firmware.
L'1.0.5 non l'ho mai provata, mi riservo di farlo alla prossima occasione. Dimmi, ma mi conviene rifare la procedura di aggiornamento toolchain alla versione attuale o posso semplicemente sfruttare la cartella 4.5.1 che uso con l'1.0.1?
@Michele
Ti ricordo che dalla 1.0.4. c'è stato un aggiornamento del bootloader della MEGA che ha risolto il problema del watchdog
* Fixed a bunch of bugs on Mega2560's bootloader (Mark Sproul)
(https://github.com/arduino/Arduino/pull/1183)
e altri problemini --> Mega2560 bootloader - various bugfixes by cmaglie · Pull Request #1183 · arduino/Arduino · GitHub
@Michele:
se può esserti utile, il succo di quel thread in inglese è questo:
lfuse 0xFF
hfuse 0xD8
efuse 0xFD
lock 0xFF
Il problema pare il lock bit, perché nel boards.txt c'è 0x0F, che attiva la protezione del bootloader per cui ti dà l'errore per via del fatto che non può accedere alla Flash. L'errore però pare in avrdude che non riesce a scrivere correttamente nella giusta locazione di memoria perché appunto 1E000 è l'area del bootloader sull'ATmega1280, cioè quello con 128K, non certo il 2560 che ha 256K di spazio.
Consigliano di usare questo:
Altra prova da fare sarebbe quella di usare avrdude 6.0, che è uscito un mesetto fa, per capire se ha ancora quel bug.
leo72:
Il problema pare il lock bit, perché nel boards.txt c'è 0x0F, che attiva la protezione del bootloader per cui ti dà l'errore per via del fatto che non può accedere alla Flash. L'errore però pare in avrdude che non riesce a scrivere correttamente nella giusta locazione di memoria perché appunto 1E000 è l'area del bootloader sull'ATmega1280, cioè quello con 128K, non certo il 2560 che ha 256K di spazio.
Il lock fuse non ha alcuna colpa, anche se lo setti a 0x0f semplicemente blocchi l'accesso all'area del bootloader dall'area del programma, ovvero non puoi eseguire routine poste nello spazio del bootloader e nemmeno leggere/scrivere da programma utente in quell'area.
Il blocco dell'accesso totale alla flash, quindi anche al programmatore, avviene solo settando i bit LB1 e LB2 a 0, quelli relativi al bootloader non hanno questa funzione.
Sul data sheet del MEGA2560, al capitolo 28.6, c'è una tabella con gli address del bootloader per i vari modelli di questa famiglia, il 1280 ha il boot a partire da 0xF000 (fino a 4k riservati) mentre il 2560 lo ha a partire da 0x1F000.
Ti rammento che la flash degli ATmega è ripartita in word da 16bit, indirizzabili singolarmente come word ma non come byte, in pratica la flash è divisa in due pagine che rappresentano msb e lsb della word, sul 1208 sono da 64k sul 2560 da 128k.
Il problema che lamenta Michele, e a quanto pare non solo lui, per me è dovuto ad un errore di address per l'inizio della verifica dopo la scrittura, questa pare avvenire correttamente visto che poi il bootloader funziona, che per qualche strano motivo parte da un address 4k più sotto di quello reale ed, ovviamente, porta ad un errore di verifica fin dal primo byte che in effetti è "0d" però si trova a 0x1f000 e non 0x1e000.
Con AvrStudio e l'AVRISP MKII la programmazione e la verifica vanno a buon fine, AvrStudio mi conferma l'allocazione del bootloader a 0x1f000, prima di questo address tutte le locazioni sono 0xff, come deve essere.
Non credo nemmeno che la colpa sia di AvrDude altrimenti darebbe sempre errori anche quando programmi tramite bootloader visto che per AvrDude è comunque un programmatore di tipo STK500 v2 sulla MEGA2560.
Ho provato apposta a caricare sulla mia MEGA2560 il software Marlin per la stampante 3D RepRap, specifico per il 1280/2560, perché sono 105k e consente di verificare che programmazione vada a buon fine anche con programmi di grosse dimensioni.
Però i lock bit sono comunque sbagliati perché se vogliono disattivare tutte le protezioni devono mettere i primi 6 bit a 1, quindi sarebbe più corretto 0b0011111111 e non 0b00001111 come fa l'Arduino.
Ora non ho visto la modalità BLB1 (che viene attivata) cos'è che stabilisce, non so se ci sono errori di protezione. Però resta il fatto che trova qualcosa che non va in verifica, quindi la lettura non viene fatta correttamente dopo la scrittura.
leo72:
Però i lock bit sono comunque sbagliati perché se vogliono disattivare tutte le protezioni devono mettere i primi 6 bit a 1, quindi sarebbe più corretto 0b0011111111 e non 0b00001111 come fa l'Arduino.
Vengono posti a 0x0f per impedire al programma di alterare l'area del bootloader, però quei bit non bloccano la lettura/scrittura tramite programmatore.
Quel settaggio è nella board del MEGA2560, anzi ce ne sono due uno a 0x3f e uno a 0x0f e se guardi il verbose postato da Michele prima Avrdude setta il lock bit a 0x3f, poi fa delle operazioni e solo prima di programmare la flash setta il lockbit a 0x0f.
In tutti i casi con il lockbit settato a 0x0f AVRISP MKII legge senza problemi l'area del bootloader e può fare la verifica dopo la programmazione quindi non può essere un problema di fuse.
Ribadisco il concetto, anche perché è chiaramente scritto nel verbose, per qualche strano motivo Avrdude inizia la verifica dal address 0x1e000 invece di 0x1f000 ed è questa la causa dell'errore.
Grazie a tutti dei contributi, purtroppo ho lezione fino alle 19 e non so stasera cosa posso fare, nemmeno sono riuscito a leggere i vostri interventi se non rapidissimamente.
Il succo della questione lo ha spiegato Astro e fin qui ci siamo: il bl viene piazzato regolarmente a 1F000 mentre la verifica parte più in basso a 1E000, dove ovviaente non c'è nulla; quindi l'errore è puramente di indirizzo di partenza della verifica mentre l'operazione va a buon fine, cosa che mi è stata confermata da Boris Landoni perché hanno lo stesso problema quando mettono il bl sul TDGino, ma poi caricano sketch enormi senza alcun ulteriore problema.
Si tratta ora solo di capire perché la verifica parte da un indirizzo errato,risolto questo si risolve l'errore; è un po' come quell'errore che avevamo all'inizio con la programmazione dei tiny (ricordi il pagel?), che non dava alcun problema, ma poi lo risolvemmo con una modifica mi pare dell'avrdude.conf, suggerita all'epoca da Dalubar, se non sbaglio; quindi uscivano quei due errori ma non creavano alcun problema, qui è la stessa cosa, ma sarebbe bello anche in questo caso rimuovere l'errore.
Proverò appena posso a modificare i fuse della Mega con quelli per vedere se effettivamente l'errore sparisce; riguardo LB e BLB mi pare di capire che stiamo perdendo i significati originali, d'altra parte non ne parliamo da più di un anno.... se necessario vedrò di riprendere il mio articolo sul Programmatore HV.
Giusto per togliere ogni dubbio allego uno screen capture di AvrStudio 4, videata del disassembler, dove si vede chiaramente che il bootloader della 2560 viene allocato a partire da 0x1f000, le prime istruzioni sono la tipica jump table creata dal compilatore.
Il primo byte della word che viene letta in 0xf1000 è proprio "0x0D" (formato Little Endian).
--pausa--
Quindi questa è la conferma assoluta che l'errore è proprio nel fatto che "chi" verifica usa un indirizzo di partenza errato, se riusciamo a sapere dov'è scritto questo valore si risolve il problema, sarebbe cosa molto buona ma io non ho idea.
@ Leo: in base alla traduzione di quel topic quei fuse impostano correttmente l'atmega2560 per i 4k di spazio per il bl a partire da 1F000, ma quelli della mega sono identici, quindi non capisco il suggerimento 
sul lock abbiamo già chiarito che non c'entra visto che non è certo lui che imposta l'indirizzo di partenza della verifica 
Dopo il primo appunto di Astro ho specificato che l'errore è chiaro che sia in verifica: in rete tutti confermano che nonostante quell'errore il bootloader venga scritto. Ma non posso aiutare nei test, non ho la Mega.
leo72:
tutti confermano che nonostante quell'errore il bootloader venga scritto. Ma non posso aiutare nei test, non ho la Mega.
Ho dato un'occhiata veloce al makefile del bootloader e vedo un gran casino, dato che AvrDude gli address li legge dal file .hex ho l'impressione che siano dei problemi nell'interpretazione da parte di AvrDude, ma non da parte di AvrStudio.
Da notare che il formato Intel HEX usato per gli AVR prevede un indirizzamento a 16 bit però è possibile introdurre dei comandi per lo spiazzamento del adress fino a 32 bit, infatti la prima riga del .hex del bootloader è proprio uno di questo comandi.
Toccherebbe provare a ricompilare il bootloder con AvrStudio, senza usare il makefile fornito, e vedere se il problema scompare.
E allora perché compare ogni tanto e non sempre.
Ci sono stati pochi casi segnalati su una miriade di MEGA vendute.