Atmega chip programmer.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 0x1E 0x98 0x01
Processor = ATmega2560
Flash memory size = 262144 bytes.
LFuse = 0xFF
HFuse = 0xD8
EFuse = 0xFD
Lock byte = 0xEF
Clock calibration = 0x9F
Bootloader address = 0x3E000
Bootloader length = 7434 bytes.
Type 'V' to verify, or 'G' to program the chip with the bootloader ...
Erasing chip ...
Writing bootloader ...
Committing page starting at 0x3E000
Committing page starting at 0x3E100
Committing page starting at 0x3E200
Committing page starting at 0x3E300
Committing page starting at 0x3E400
Committing page starting at 0x3E500
Committing page starting at 0x3E600
Committing page starting at 0x3E700
Committing page starting at 0x3E800
Committing page starting at 0x3E900
Committing page starting at 0x3EA00
Committing page starting at 0x3EB00
Committing page starting at 0x3EC00
Committing page starting at 0x3ED00
Committing page starting at 0x3EE00
Committing page starting at 0x3EF00
Committing page starting at 0x3F000
Committing page starting at 0x3F100
Committing page starting at 0x3F200
Committing page starting at 0x3F300
Committing page starting at 0x3F400
Committing page starting at 0x3F500
Committing page starting at 0x3F600
Committing page starting at 0x3F700
Committing page starting at 0x3F800
Committing page starting at 0x3F900
Committing page starting at 0x3FA00
Committing page starting at 0x3FB00
Committing page starting at 0x3FC00
Committing page starting at 0x3FD00
Written.
Verifying ...
No errors found.
Writing fuses ...
LFuse = 0xFF
HFuse = 0xD8
EFuse = 0xFD
Lock byte = 0xEF
Clock calibration = 0x9F
Done.
Type 'C' when ready to continue with another chip ...
The only clue is that the lock byte is reported as 0xEF (both at the start and at the end of the readout), which differs from the 0xCF on Nick's webpage, and differs again from the 0x2F in the signatures structure of the code. However, if I've read the datasheet correctly (table 28-3), BLB1 mode 2 ("SPM is not allowed to write to the Boot Loader section") is set with either 0x2F or 0xEF.
Does the opening 0xEF mean I can't write the bootloader and, if so, any ideas for how I get out of this?
I had a similar experience here. Be sure to read Nick's reply at the end. The fuses were the problem because of their effect on the clock rate of the 16u2. Fortunately, I had a logic analyzer to see what was happening between the 16u2 and the 2560.
I'm not real sure about this, but I think you may have to perform a "chip erase" in order to change the (some?) fuses. That's accomplished with the "-e" option in the avrdude command I used in the post above. I've never used an Arduino as an ISP, but it looks like avrdude supports it with the "-c arduino" option. That's not Nick's sketch, though.
but despite reporting success I'm still unable to upload to the Mega.
What are the symptoms? (error messages) Turn on verbose uploading and copy and paste what you get, please.
Looks to me like the bootloader installed, no problems there. Is this a Mega board, or a stand-alone or personal creation? Is it clocked at 16 MHz by the crystal?
If you get stuff installed, and the fuse settings are right (which they look to be) a failure point now would be the wrong clock to the processor, or possibly a bad USB interface chip.
If you have a ICSP header for the USB chip (it will be near the USB socket) try plugging into that and at least seeing if you see the USB chip signature.
This is a standard Mega 2560 using the onboard clock. I suspect it is an R1 or R2 as it doesn't have an ISCP header near the USB chip, so I'm afraid I can't give you the chip signature.
Verbose error log on trying to upload the 'blink' example is below
There is nothing being received, so I doubt it is the lock bits. For that to be the problem the programmer would respond but be unable to write or verify.
Have you tried the loop-back test? (see the Troubleshooting part of the forum)
Also try placing LEDs (with resistors, eg. 470 ohms or thereabouts) into both D0 and D1 (Rx0 and Tx0) on the board, and see if they flash at all when you attempt to upload.
Put the negative side (cathode) into D0 and then the resistor in series, and then the positive side (anode) into the +5V pin. That way it will flash when it receives data (as async comms is normally high when inactive).
You should see both LEDs flash as the sketch tries to be uploaded. If not it is being stopped at the USB chip.
I've just run the loopback test and it works correctly (I used Serial Monitor), reflecting all data entered.
I've also just tried the LED test on DO and D1. When uploading, I get a single flash from D0 (and from the onboard Rx0 LED) every 10 seconds, or thereabouts. I get nothing from D1 or the Tx0 LED.
I guess this means the USB chip is playing up? Whilst I don't have an ICSP header adjacent to the USB chip, there are 3 x 2 vias in the board at that spot that I could solder to if that would help, or is there another way to talk to the USB chip?
My apologies, this turned out to be a red herring. Turns out the problem was with the USB connection on my laptop; nothing to do with the Arduino (although oddly the laptop managed to upload to another Mega and a Uno before finally packing in).