Nick Gammon's Atmega_Hex_Uploader

I am using Nick Gammon's HEXUploader V1.9 and I think it is a fantastic piece of code.

I have a custom board with 3 MCU (1 ATMEGA328P and 2 ATMEGA2560) so the ATMEGA328P can program the other two MCU. This code worked hundreds of times for over one year but today one of the MCU stopped working and I can't even program it (with AVRISP or via FTDI).

With the hints I received on this topic from 2013 http://forum.arduino.cc/index.php?topic=193291.0 I managed to "merge" the code with the bootloader and program it with HEXUploader (I included the stk500v2 bootloader in my piece of code).

Today, when trying to upload a new code to the 2 ATMEGA2560 MCU I received the following message:

Attempting to enter programming mode ...

Entered programming mode OK.
Signature = 0x1E 0x98 0x01 
Processor = ATmega2560

Flash memory size = 262144 bytes.
LFuse = 0xFF 
HFuse = 0xD8 
EFuse = 0xFD 
Lock byte = 0xCF 
Clock calibration = 0xA0 
Processing file: nfw/mcu1.hex
Checking file ...

################################################################
Lowest address  = 0x0
Highest address = 0x3FFD9
Bytes to write  = 102612
No bootloader.
Suggest making high fuse = 0xD8 
Attempting to enter programming mode ...

Entered programming mode OK.
Processing file: nfw/mcu1.hex
Erasing chip ...
Writing flash ...

################################################################
Written.
Processing file: nfw/mcu1.hex
Verifying flash ...

################################################################
No errors found.
No bootloader.
Setting high fuse = 0xD8 
Done.
new MCU2 FW!
Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x98 0x01 
Processor = ATmega2560
Flash memory size = 262144 bytes.
LFuse = 0xFE 
HFuse = 0x00 
EFuse = 0xFE 
Lock byte = 0x00 
Clock calibration = 0x00 
Processing file: nfw/mcu2.hex
Checking file ...

################################################################
Lowest address  = 0x0
Highest address = 0x3FFD9
Bytes to write  = 94050
No bootloader.
Suggest making high fuse = 0x00 
Attempting to enter programming mode ...
Entered programming mode OK.

Processing file: nfw/mcu2.hex

Erasing chip ...
Writing flash ...

################################################################

Written.
Processing file: nfw/mcu2.hex
Verifying flash ...
Verification error at address 0. Got: 0x00  Expected: 0x0C 

(...)

################################################################

#Verification error at address 10164. Got: 0xB2  Expected: 0x0E 
Verification error at address 10165. Got: 0xB2  Expected: 0x94 
(...)
Verification error at address 101C8. Got: 0xE4  Expected: 0x9C 
Verification error at address 101C9. Got: 0xE4  Expected: 0xE0 
###############################################################

28053 verification error(s).
First 100 shown.
No bootloader.
Setting high fuse = 0x00 
Done.

As you see the first MCU was successfully programmed and the 0xD8 high fuse was suggested and set. Everything went fine.

However, before programming the second MCU a list of fuses, lock byte and clock calibration was shown and it is different from the first MCU (I am using the same chip) and after this programming operation I am no longer able to program the unit.

Any suggestions/hints are appreciated.

Thank you.

The fuse settings look odd. Did you say you modified my original code?

Do you have an external crystal?

Hello Nick, many thanks for your reply.

Yes, I do have an external 16MHz crystal, it is the same as any arduino board. My crystal is like this one : |500x375

I did not change your code. As you see, the fuses list for the first MCU is pretty accurate. What can possible be wrong with MCU#2?

I don't know except for wiring or noise problems.

Will the hex uploader load an AVR with no bootloader or lock on flash?

The hex is for 328eForth, less than 6K. http://www.offete.com/328eForth.html

Anyway will the hex uploader get upset over no bootloader and the lock bits not set? The hex file has the lock bits, right?

The hex uploader does not required a bootloader. As it erases all flash initially, any bootloader would be erased anyway.

It doesn't care about the lock bits, unless they prevent it from operating.

The hex file does not have lock bits in it.

Basically, if the hex file starts at address 0, it is assumed to be "pure code" and is inserted as such at address zero, and the fuses altered to commence executing at the code (ie. no bootloader). If the hex file starts at a valid bootloader address for the target chip it is assumed to be a bootloader, and the fuses altered accordingly. If the hex file starts at some other address, an error message is raised.

[quote author=Nick Gammon link=msg=2177164 date=1428460158] I don't know except for wiring or noise problems. [/quote]

I would say that there are no wiring problems because this same piece of code worked for over one year. Regarding the noise issues, I am not so sure.

I guess that for same reason I don't know at this moment (maybe due to noise?), the fuses/lock byte from the target MCU were not correctly read and some faulty values were written. Perhaps the values were also written on wrong addresses damaging the unit (I tried to program the bootloader with an AVRISP and I can't even read the processor signature). Does my "theory" make any sense?

Certainly if you operated the processor out of spec for some reason (eg. too much current from an output pin, or too high a voltage on an input) you may have damaged it.