Run those settings thru a fuse calculator, see what they do for you:
Totally SOLVED !!
And my sincere thanks for your input and very valuable comments and contribution.
I posted on av AVR related forum, about the different fuses - the Mega2560 ones that everyone says should work, and the very different ones that I found in a single post ( that did work ).
Part of the reply that I got was :
The differences between the two sets of fuses are: - The first one assumes there is an external clock source in form of a crystal on your board, the second uses the internal RC oscillator for clocking the AVR. - The first one sets the AVR to start executing a so called bootloader (a program stored in a special part of the AVR, that in turn will communicate over some arbitrary media and program the application proper into the rest of the flash). The second one does not have this bootloader set. -The second one had disable "brown-out detection", a way for the AVR to detect low voltage conditions and to do a reset if one has occurred.
I also received a link to http://www.frank-zhao.com/fusecalc
I applied the fuses that the Arduino forum experts said should be used : -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xFD:m -U lock:w:0x0F:m
I then looked for the bootloader that was mentioned.
Found it in the Lockbit section : -- Boot Loader Protection Mode 3 : LPM and SPM prohibited in Boot Loader Section.
not certain exactly what that means, but since I an using avrdude to erase the chip and then upload the hex file, I assumed that the bootloader ( or protection of the bootloader section ) is not required, and changed it to : -- Boot Loader Protection Mode 1 : No Lock on LPM and SPM in Boot Loader Section.
This changed the lock fuse to: -U lock:w:0xFF:m
Used AVRdude to upload the hex file with these fuses via the AVR Programmer to the ICSP pins, and working perfectly.
I am so pleased to have learnt something ( with help, of course ) that I thought I would never understand.
Thanks again for your input - you certainly helped steer me in the right direction.
Glad you got it worked out.
Here’s the details of the bits from the data sheet. More reading is required to interpret the bits for making changes.
Did you actually get rid of the error when when you burn the bootloader?
We are able to reproduce the error:
avrdude: verification error, first mismatch at byte 0x1e000 0xff != 0x0d avrdude: verification error; content mismatch
Using either the IDE (1.0.1 - 1.0.5) or avrdude. So it's not the IDE, it's avrdude that is creating the error. We were also able to verify that the bootloader is indeed being burned correctly at 0x3E000. What we can't figure out is why is avrdude looking for it at 0x1E000 on the verify cycle!!? Does anyone have any insight into that?
I know that Mr. Gammon's approach might work well, but shouldn't this be fixable?
From what I can recall, I understand ( and I only have limited mental free space, so trust nothing I say ) that the AVRdude, when used, wiped out the bootloader section on the chip.
Then it uploaded the hex file, and I think that AVRdude read the existing fuses from the board ( which told it to start at position 'x3' because positions before x3 were protected for the bootloader ), wrote the hex file to the chip starting at position 'x3', re-wrote the fuses, and then tried to verify starting at position 'x1' ( x1 and x3 are just variables, as I don't know the correct terms to use - they are just different addresses on the chip ). As it could not find the data in x1 that it had written to x3, it gave the error of a mismatch.
My solution was to first replace the fuses ( see reply posted just above ) and change : -U lock:w:0xFF:m
so that it disabled the protection of the bootloader area.
This allowed AVRdude to write the hex file ( which was the hex of the bootloader ) starting at position x1 ( instead of x3 ), verification passed, and I was then able to connect the board to the IDE again because the bootloader now existed in the correct / expected space on the chip.
Sorry that I can't be more technical or accurate than that, but I am sure that some of the experts will appear soon and most likely shoot down my post and provide a better / more accurate / completely different explanation.
to add to your statement of :
it's avrdude that is creating the error. We were also able to verify that the bootloader is indeed being burned correctly at 0x3E000. What we can't figure out is why is avrdude looking for it at 0x1E000 on the verify cycle!!? Does anyone have any insight into that?
I think that when AVRdude writes, it starts at the first non-protected address - in this case 0x3E000
When it verifies, it does not expect, or take into account, that there is a bootloader on the chip in a protected area, and assumes that the data was written starting at the first address 0x1E000.
The only way to make / force AVRdude to burn the bootloader to the correct / expected bootloader location, is to disable the protection of that area.
AVRdude seems to be used often if the user wants to use the max space on the chip for the sketch, and is prepared to sacrafice the bootloader to free up space. Removing the bootloader means you can't access it with the IDE, so maybe AVRdude expects the bootloader to not be there. The fact that it wrote the data starting at 0x3E000, but is looking to verify at 0x1E000 seems to indicate that it does not remember the exact starting address, but rather uses two different methods : when writing the data, start at the first non-protected address. But when verifying, start at the first address.
I think it's actually worse. I think it's a coding error. avrdude is not taking the extended addressing into account when it verifies. I wonder if the same thing would happen on an Atmega2561, or is it limited to the 2560, which is just a extended addressing version of the 1260. 0x1E000 is where the bootloader goes on the Atmega1260. Anyway, it's something they should fix, but if they did it may be a while until it gets into the Arduino release which is always quite far behind on its version of avrdude.
BillO: I think it's actually worse. I think it's a coding error. avrdude is not taking the extended addressing into account when it verifies. I wonder if the same thing would happen on an Atmega2561, or is it limited to the 2560, which is just a extended addressing version of the 1260. 0x1E000 is where the bootloader goes on the Atmega1260. Anyway, it's something they should fix, but if they did it may be a while until it gets into the Arduino release which is always quite far behind on its version of avrdude.
I don't see it as a coding error. The flags on the chip tell AVRdude that the bootloader area is protected, so AVRdude used the first available address after that protected space to upload the hex file.
To make AVRdude write in the protected area, you need to un-protect the reserved bootloader area.
Under normal conditions of just wanting to upload a normal sketch, the existing way it is working should be fine. But the fact that you are wanting to upload a bootloader, you need to unlock that protected area. Maybe this is a positive feature of AVRdude in that it will not simply overwrite the flag settings for the protected area. Having said that, it does seem to have a bug in the starting point when doing the verification.
I think that you only need a bootloader if using the IDE to load sketches, but if you are going to use AVRdude to upload the hex, you can disable the protection and use the full chip space.
I think you'd get the same error if you loaded a program of over 131072 bytes in length without the bootloader.
BillO: I think you'd get the same error if you loaded a program of over 131072 bytes in length without the bootloader.
Sorry, but I am a bit lost.
I thought we were discussing how to load and verify the Bootloader ( I think size around 23,000 bytes ).
I think that as long as the bootloader area is protected, AVRdude will ( and correctly so, imho ) not write into that area. Unfortunately it tries to verify from the first address, not taking into account the protected area.
Unlock the area, write the bootloader, lock it back up again. Then upload sketches using the IDE.
If you don't need the IDE and intend uploading with AVRdude every time, just unlock the area and use it, and leave it unlocked. No point in protecting a bootloader area when there is no bootloader.
What I am saying is, that it does not mater what you load up. Bootloader or other code (as long as it's not loaded via the bootloader itself). Once it goes beyond the 128K boundary you will get the verify error. In all the cases we tried, we did erase the flash and set the lock byte to 0xFF (actually 0x3F or 0x7F are okay as the two highest order bits are always '1'). That's the standard way of loading code via avrdude, unless you have something you want protected, like a bootloader. It's not forgetting where it put things, it's 'forgetting' to enable the extended addressing during verify.
Have you tried loading a smaller sketch and seeing if it verifies OK ?
Apart from that, I must admit that the technicalities are way above my level, so would have to wait for the guru's to post.
If it helps at all, the content of my batch file to upload is :
cd\Program Files\arduino-1.0\hardware\arduino\bootloaders\stk500v2 avrdude -v -p atmega2560 -c usbasp -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfd:m -U lock:w:0x3f:m -U flash:w:stk500boot_v2_mega2560.hex
Bootloader in only 512 to 1024 bytes, not 23,000.
CrossRoads: Bootloader in only 512 to 1024 bytes, not 23,000.
That's odd, and I don't dispute your info. But on my PC, the properties of stk500boot_v2_mega2560.hex show Size : 22.4 KB (22,989 bytes)
Is the bootloader hex on my pc the wrong size, or does it change when uploaded to the board ? Or possibly the bootloader is not the complete hex file ?
That might be the size of the file, with 2 letters to represent a byte: B01010101 = 55 for instance, with each 5 needing a byte, then data for the address of the bytes, data for a checksum, and so on.
These files are in HEX format. See below which is part of a bootloader file:
:02 0000 02 30 00 CC :10E000000D94F6F20D941FF30D941FF30D941FF36E :10E010000D941FF30D941FF30D941FF30D941FF334 :10E020000D941FF30D941FF30D941FF30D941FF324 :10E030000D941FF30D941FF30D941FF30D941FF314 :10E040000D941FF30D941FF30D941FF30D941FF304 :10E050000D941FF30D941FF30D941FF30D941FF3F4 :10E060000D941FF30D941FF30D941FF30D941FF3E4 :10E070000D941FF30D941FF30D941FF30D941FF3D4 :10E080000D941FF30D941FF30D941FF30D941FF3C4 :10E090000D941FF30D941FF30D941FF30D941FF3B4 :10E0A0000D941FF30D941FF30D941FF30D941FF3A4 :10E0B0000D941FF30D941FF30D941FF30D941FF394 :10E1500000415652204C69624320566572203D2092 :10 E160 00 00 47 43 43 20 56 65 72 73 69 6F 6E 20 20 3D 20 3F
Each line starts with a colon then a 2 character byte count (in hex) for the record. This is followed an address in some records. Then a 2 character record type. Then data. Then a 2 character check-sum. A type 02 record contains a segment address as it's data like the first line above which I have broken out. The last line is a type 00 data record. I broke this one out as well. So, each byte of data written to the flash is represented by 2 bytes in the hex file, and for every 20 of thoes there are some 12 additional characters describing what to do with the data as well as a few extra characters in each file.
Having the same problems while programming the 2560 with USBasp
The 8u2/16u2 gives no problem. The bootloader loads and gives flashes. Still getting
an error message after the bootloader is uploaded.
But with a sketch (like the ‘blink’ sketch), it won’t work.
Can readout it is programmed ok.
But for uploading sketches and it’s all working, both IDE & Atmel Studio,
what are the right settings of the fuses? Is this/there a definely solution?
By the way, have also looked at the AVRdude source and the config.
Could be possibly the solution there making?
Note: the Attiny programmer can also not programm more
then 64Kb, also described in the in the AVRdude document.