MEGA 2560: affrontiamo l'errore "first mismatch at byte 0x1e000 0xff != 0x0d"

[astrobeed]

Astro ha detto che il bootloader non si posiziona sugli ultimi 4k dei 256k ma sugli ultimi 4k dei primi 128k

Attenzione a questa cosa, probabilmente mi sono spiegato male io, il bootloader viene caricato nelle ultime 4k word della flash, sugli ATmega la flash è organizzata in due pagine di cui una è il lsb e l'altra l'msb della word, quindi sul ATmega2560 il limite si trova a 128k word della flash.
Sugli ATmega il program counter indirizza solo le word della flash e non i singoli byte, infatti se scrivete nella flash una variabile di un solo byte questa poi va ad occupare due byte (una word) nel conteggio della flash usata dal programma.
Per essere più chiari, il bootloader viene realmente scritto in fondo alla flash del 2560, la questione del limite a 128 kbyte, quindi 64kword, della toolchain standard di Arduino è legata al limite del compilatore che più di 64kword (128k) non indirizza.
Da notare che l'IDE dopo la compilazione fornisce l'occupazione della flash sotto forma di kbyte e non kword, questo trae facilmente in inganno.

[Michele Menniti]

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.

Scusa Astro, sono andato a trovarmi il tuo intervento all'inizio del Topic, la frase mi sembra inequivocabile, ma mentre nell'interventoqui quotato mi pareva di aver capito tutto, nel tuo ultimo intervento non c'ho capito niente, quindi devo per forza addebitare la questione alla mia ignoranza e non ad un tuo errore.
Comunque sia sappi che aspetto con ansia che tu sveli la soluzione al problema, sono certo che risolveremo tutto d'un colpo, mentre resta ancora a me l'onere di verificare gli errori avuti domenica e sui quali non mi sono soffermato. Tra tutti principalmente il fatto che con l'IDE 1.0.1 non sono riuscito in alcun modo a caricare uno sketch sulla mia Arduino MEGA ADK (quindi non il chip in stand-alone), cosa invece riuscita perfettamente con l'IDE 0022.

[astrobeed]

Scusa Astro, sono andato a trovarmi il tuo intervento all'inizio del Topic, la frase mi sembra inequivocabile, ma mentre nell'interventoqui quotato mi pareva di aver capito tutto, nel tuo ultimo intervento non c'ho capito niente,

E in effetti il mio primo intervento trae in inganno, avevo dato per scontato il concetto della word a 16 bit usata per la flash degli AVR.
Vedila in questo modo, la flash è composta da 128k locazioni utili, ciascuna di queste occupa due Byte per un totale di 256kbyte, il bootloader viene posto in fondo a queste 128k locazione, ovvero a partire dall'indirizzo 0x1f000 che corrisponde a 126976, infatti se gli sommi 4k, ovvero 4096, si ottiene 126976+4096 = 131072 ovvero 128k.
Mi rendo conto che il concetto di word a 16 bit spiazza un pochino chi è abituato a pensare in termini di byte e con mcu a otto bit dove la reale word elaborabile dalla cpu sono solo otto bit per volta.

[Testato]

sta cosa delle word mischia proprio le cervella 

scoperta cosa interessante, ho due usbasp in mano, con uno non ho l'errore di verifica, con l'altro si 
(con ArduinoISP c'e' sempre)

a questo punto io voto per un problema proprio in ArduinoISP

il mio secondo problema invece e' fisso con tutti e tre i programmatori, ho provato a resettare in tutti i modi. il discorso di settare diversamente i fuse si puo' fare, pero' spetta, devi prima darmi conferma che a te funziona la cosa, a me e' fisso il problema

[Testato]

Ho aggiornato il fw al programmatore che sbagliava la verifica ed ora anche lui non sbaglia la verifica.
resta ArduinoISP con il problema, Astro ci ho preso ? 

[leo72]

Ho aggiornato il fw al programmatore che sbagliava la verifica ed ora anche lui non sbaglia la verifica.

Bene, quindi implicitamente mi dai ragione. Dopo una prosopopea in cui dicevi che non sai spiegarti, che non ti capisco ecc... alla fine confermi quanto stavo dicendo, ossia che era il programmatore che scriveva dove non doveva... 

[astrobeed]

resta ArduinoISP con il problema, Astro ci ho preso ? 

Infatti sto per puntare il dito proprio contro lo sketch Arduino ISP, però prima di farlo devo eseguire delle verifiche utilizzando questo sketch, cosa che non potrò fare prima di fine settimana.

[PaoloP]

Piccolo OT.

Sugli ATmega il program counter indirizza solo le word della flash e non i singoli byte, infatti se scrivete nella flash una variabile di un solo byte questa poi va ad occupare due byte (una word) nel conteggio della flash usata dal programma.

Quindi è inutile utilizzare il tipo byte poiché in flash usa lo stesso spazio di un int o non ho capito qualcosa?

[astrobeed]

Quindi è inutile utilizzare il tipo byte poiché in flash usa lo stesso spazio di un int o non ho capito qualcosa?

Il tipo di dato deve sempre essere quello corretto, indipendentemente da come viene memorizzato, altrimenti rischi di andare incontro a comportamenti inattesi, non necessariamente errati, dovuti al casting che possono far perdere molto tempo prima di risalire alla causa.

[leo72]

Se ti riferisci ai dati, questi finiscono in RAM, non in Flash, per cui se usi una variabile "int" essa ti occupa 2 byte di RAM, non di Flash. L'occupazione della flash è data dal valore di inizializzazione, che viene memorizzato nello sketch e quindi in Flash ma poi trasportato in RAM durante la creazione della variabile.

[PaoloP]

Giusto, non ci avevo pensato. Continuerò ad usare il tipo più piccolo possibile compatibilmente al suo uso nello sketch.

[PaoloP]

Ho fatto un compare dei file e ho visto che l'ArduinoISP.pde della 0022 è diverso dall'ArduinoISP.ino della 1.0.5.
Non cambia invece tra 1.0.5 e 1.5.4 (o Nightly Build).

[Testato]

No leo,
Sai bene che non ho problemi ad ammettere eventuali miei errori, ma in questo caso continuo a non capire il tuo appunto.
Spiegamelo meglio, io ci provo, o a me o a te manca qualche elemento.
A questo punto parto al contrario, dal dire cosa tu affermi.
Se ho capito tu dici che il vecchio fw usbasp non sa scrivere il bootloader, quindi in questo caso il bootloader non funziona.
Io per bootloader funzionante intendo che dopo averlo caricato, butto via il programmatore, attacco la mega via USB, e ci programmo blink.
Quedto funziona, il blink parte regolarmenye e quindi il BL è funzionante. Quindi anche il penultimo fw usbasp riesce a caricare bene il bootloader.
Siamo daccordo ?
Lasciamo da parte l errore di verifica e lasciamo da parte i problemi Carica tramite Programmatore.

[Testato]

Paolo è normale che siano diversi perché arduinoISP vecchio non funzionava proprio sulla 1.0
Ciblavorarono leo lesto e michele ci ha scritto anche un articolo se ricordi

[leo72]

Testato, purtroppo io sono menomato rispetto a voi, nel senso che non ho una Mega per fare test. Quindi non so esattamente come si comporti questa scheda. Ho ricostruito la vicenda cercando di trarre dei dati da quanto scrivete, ma non è semplice.

L'unica cosa certa è che l'USBasp col firmware 2009 non è capace di scrivere oltre i 128KB, questo è un dato di fatto dichiarato dallo stesso autore. Dove scriva e cosa scriva non lo so per certo, perché ripeto non ho una scheda per verificare. Mi fido di quanto scrivete voi. Analizzo e dati e ragiono su ciò che non mi torna. Se io so che l'USBasp non può scrivere nel settore corretto, come fa il bootloader a partire se il jump messo nella locazione $0000 punta ad una cella di memoria dove non c'è nulla?
Ecco qui seguo questo filo logico e concludo che c'è una discrepanza tra quanto affermi te e quanto invece dovrebbe accadere, sempre secondo la mia analisi.