Arduino Mega 2560 Bootloader (apparently) burnt correctly but not working

Hi,

I'm having some trouble with my Arduino Mega 2560 Rev. 3 board regarding the bootloader.
It all worked well with the preburnt bootloader installed by default. Then I had to write a sketch without the bootloader, therefore I used an ISP-programmer and programmed it directly (with the Arduino 1.0 IDE -> using programmer) and the prog was also working well, so the ISP-configuration works just fine. By doing this the original bootloader is (of course) erased/overwritten.

Now I wanted to revert back to the original bootloader and I'm experiencing serious problems:
I selected burning bootloader (the original STK500v2 delivered with the 1.0 IDE on Win7 x64 which is the default for the Mega 2560) in the Arduino IDE. This is done in around 1 minute and after finishing avrdude says it has worked.

But I just can't get any new programm onto the board. I always get a timeout when uploading a new programm via USB/bootloader (I enabled verbose output). Furhermore when powered up, the L-led (internal led at PIN 13) won't flicker once as described in the bootloader troubleshooting, but remains active indefinitely. When uploading the RX/TX leds also won't blink - just once when started and then from time to time (I assume when avrdude tries to reset the arduino).

I tried the loopback test and it works just fine, I also reinstalled the driver, stil not working, but the problem shouldn't be located there, because the USB-ATMEGA interface bridge works just fine, should it?

The Arduino itself is (probably) also fine, as programming it directly per ISP works, too (using the blink example to keep it as simple as possible)
There are no other connections (I removed my shield), except the ISP when burning. I tried it by using Arduino on board power (ISP-Power off) and ISP-Power only. The IDE/avrdude always says it worked (as long as the isp cable is pluged in ;)). The ISP pins are also connected correctly, as the direct programming of sketches works.

I suspect that either the bootloader isn't really burned to the Arduino (despite it says it does and the verbose output says it also verified the code and the fuse settings and everything is fine) or there are some errors with the fuse settings (I'm using the default ones, I changed neither bootloader.hex nor the settings regarding it).
The other possibility is that there is some incompatibility with the bootloader hex file delivered with 1.0 and the Mega third revision, but I highly doubt it.

Is there some test I can run to check where the error is located?
What can I do to get it working?
I'm really running out of ideas. I burnt different Mega 2560 bootloaders multpily times (in the end I used the original one) and spend hours on the internet, but all similiar problems were either not resolved at all or the solution isn't working with my board.

Thank you for your help!
Best regards!

For the sake of completeness:
This is the error message when uploading (USB at COM3):

Using Port                    : \\.\COM3
Using Programmer              : stk500v2
Overriding Baud Rate          : 115200
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: Recv: 
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]

And this a snippet of the logfile (removed all the send/receive info due to the size limit) when burning the bootloader (ISP at COM4):

 Using Port                    : \\.\COM4
 Using Programmer              : stk500v2
stk500v2_getsync(): found STK500 programmer
 AVR Part                      : ATMEGA2560
 Chip Erase delay              : 9000 us
 PAGEL                         : PD7
 BS2                           : PA0
 RESET disposition             : dedicated
 RETRY pulse                   : SCK
 serial program mode           : yes
 parallel program mode         : yes
 Timeout                       : 200
 StabDelay                     : 100
 CmdexeDelay                   : 25
 SyncLoops                     : 32
 ByteDelay                     : 0
 PollIndex                     : 3
 PollValue                     : 0x53
 Memory Detail                 :

						  Block Poll               Page                       Polled
   Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   eeprom        65    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
						  Block Poll               Page                       Polled
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   flash         65    10   256    0 yes    262144  256   1024  4500  4500 0x00 0x00
						  Block Poll               Page                       Polled
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
						  Block Poll               Page                       Polled
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
						  Block Poll               Page                       Polled
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
						  Block Poll               Page                       Polled
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
						  Block Poll               Page                       Polled
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
						  Block Poll               Page                       Polled
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

 Programmer Type : STK500V2
 Description     : Atmel STK500 Version 2.x firmware
 Programmer Model: STK500
 Hardware Version: 3
 Firmware Version Master : 2.10
 Topcard         : Unknown
 Vtarget         : 0.0 V
 SCK period      : 3.3 us
 Varef           : 0.0 V
 Oscillator      : Off
AVR device initialized and ready to accept instructions
###
Device signature = 0x1e9801
reading input file "0x3F"
writing lock (1 bytes):
##
1 bytes of lock written
verifying lock memory against 0x3F:
load data lock data from input file 0x3F:
input file 0x3F contains 1 bytes
reading on-chip lock data:
##
verifying ...
1 bytes of lock verified
reading input file "0xFD"
writing efuse (1 bytes):
##
1 bytes of efuse written
verifying efuse memory against 0xFD:
load data efuse data from input file 0xFD:
input file 0xFD contains 1 bytes
reading on-chip efuse data:
##
verifying ...
1 bytes of efuse verified
reading input file "0xD8"
writing hfuse (1 bytes):
##
1 bytes of hfuse written
verifying hfuse memory against 0xD8:
load data hfuse data from input file 0xD8:
input file 0xD8 contains 1 bytes
reading on-chip hfuse data:
##
verifying ...
1 bytes of hfuse verified
reading input file "0xFF"
writing lfuse (1 bytes):
#
1 bytes of lfuse written
verifying lfuse memory against 0xFF:
load data lfuse data from input file 0xFF:
input file 0xFF contains 1 bytes
reading on-chip lfuse data:
#
verifying ...
1 bytes of lfuse verified
avrdude done.  Thank you.
Device signature = 0x1e9801
NOTE: FLASH memory has been specified, an erase cycle will be performed
reading input file "...\stk500boot_v2_mega2560.hex"
writing flash (262106 bytes):
# 
262106 bytes of flash written
verifying flash memory against ...\stk500boot_v2_mega2560.hex:
load data flash data from input file ...\stk500boot_v2_mega2560.hex:
input file ...\stk500boot_v2_mega2560.hex contains 262106 bytes
reading on-chip flash data:
# 
verifying ...
262106 bytes of flash verified
reading input file "0x0F"
writing lock (1 bytes):
#
1 bytes of lock written
verifying lock memory against 0x0F:
load data lock data from input file 0x0F:
input file 0x0F contains 1 bytes
reading on-chip lock data:
#
verifying ...
1 bytes of lock verified
avrdude done.  Thank you.

Sigh. The AVRDude changed to a new version in Arduino 1.0, there seems to be some issues with the new version. But no one seems to be fixing it. I fixed my copy, and it's now 100% reliable for me.

Hi, thanks for your answer.

Unfortunately this issue seems not to be related to a specific Arduino software version, at least for me. I tried flashing with 0022 and the bootloader is still not working (i.e. starting).

I also fetched the flash memory from the device (with avrdude) and both times (burnt with 1.0 and 0022) the whole memory is erased (0xFF) as expected and some code is written at the end: likely the bootloader (several parts of the binary data seem to correlate to the original hex file and several text strings as "ATmega2560 Arduino explorer stk500V2 by MLS Bootloader" can be found) which goes from :20E0E00 to :20FFA000.

The content of the flash (without any programm) should be the same on every (new burnt) Arduino Rev. 3, right?
In this case it should be able to verify it by checksum.
Mine is (MD5): 161e97a2d4211e5193c4bf9bd3c7c46e
flash memory: exactly 262106 Byte (256 KByte)

Regards

The code for fetching the flash:

avrdude -C "avrdude.conf" -v -p atmega2560 -c stk500v2 -P\\.\COM4 -Uflash:r:flash.hex:r

Could anyone please post the md5 hash of their Arduino Mega 2560 Rev. 3 flash memory content (without any sketchs uploaded, i.e. only the newly burnt bootloader) so that I can verifiy my boards integrity?

The code for doing this (via ISP-Programmer) is the following:

avrdude -C "avrdude.conf" -v -p atmega2560 -c stk500v2 -P\\.\COM4 -Uflash:r:flash.hex:r

Thanks!

Hello,

I'm trying to do the exact same thing, and face the same problem.
I'll try (later) downgrading my IDE version and/or getting the baudrate down.

A small question to Coding Badly / suggestion to TheBassJunkie tough:
I initially plugged my attiny as pictured in the first post, but such a wiring matches Uno/Duemilanove pins, while Mega should use pins 50->53. Can you confirm ? (and does the ArduinoISP sketch needs to overload the arduino_pins.h values ?)

BTW, I've tried as well with a Nano 3.1 (gravitech), without success as well.
I'll let you know of any progress on my side if any.

Hope to see this problem solved soon.

Cheers

Hi Fellow suffers,
I have exactly the same problem as blacksea, though I have not investigated as deeply as he has. Mine is very simple and very confusing. I down load any one of the Arduino environments from arduino.cc. I connect my Arduino AVRISP Mkii with latest firmware flashed using AVR Studio 6. to my mega2560 Crius flight board. I then changed the USB drivers to libusb as I am told that the Jango drivers are not compatible with arduino. Using the Tools menu I select AVRISP Mkii as my programmer and 2560 as the target board. I then burn the Bootloader from the same menu, the lights on the AVRISP flash correctly and after about a minute the Arduino IDE reports Bootloader flashed or words to that effect. I now plug in a USB lead and the Arduino recognises the Port. I then try and down load the Blink Sketch and get the same errors as blacksea. I have repeated this process with 3 versions of Arduino 022 1 and 1.0.1. If I now down load Blink via ISP using the AVRISP Mkii or either of USBtinyISP or USBasp, then the program is downloaded without a problem.
I have also used this method, ISP Port, to down load a complex sketch used for the control of a quad copter (MultiWii2.1) this sketch downloads no problem via the ISP Port yet refuses to down load via both USB and FTDI. I can then ,via the USB or seperate FTDI interface, monitor the execution of the program down loaded vis ISP, using a GUI program associated with MultiWii2.1. This program sends and receives data via the USB and FTDI interfaces without a problem, hence the USB and FTDI interfaces must be OK. I have also changed the USB lead and the USB to FTDI cables. I have tried the same tests with 3 different Arduino devices ,Nano V3.0, UNO and a propiatary Flight controller board incorporating a ATmega328 all accepted the bootloader and subsequently I was able to download sketches to them on the USB port.
There are so many threads on forums all "pussy footing" around this topic. I have to ask my self if any one knows what the **** is going on with the ATmega2560 and its bootloader? If any one has the definitive answer why are they not sharing it with the rest of us mere mortals. Even on this one Forum some one claims that he has solved the problem yet declines or to be more charitable forgets to share the necessary code or information. I wonder why???

Don't suppose I will get a reply but I will keep trying.

Regards

John

WSWhitby:
... If I now down load Blink via ISP using the AVRISP Mkii or either of USBtinyISP or USBasp, then the program is downloaded without a problem...

Question, does your USBasp have a jumper for "SLOW CLK"? I know I had to spoon feed the bootloader to some Atmega1284p types.

There is something definitely odd about the 2560 bootloader and the Arduino IDE. I tested back to 0021 and I get a verification error. The error does not appear to affect anything, uploading is not a problem. I did get a long and short flash on the "bootloader blink" sketch. I reburned the 1280 (on a 1280 clone) bootloader with no issues. Slow Clk does nothing on USBasp.

Tested with USBasp and Arduino ISP.

Hi All,
My problem is for sure not with any of the 3 programmers I have used on the ISP port. All are able to down load sketches to a number of boards, 2 with Atmega2560's and 3 with ATmega 328's. I have simply used 3 different programmers to try and illuminate the problem. My problem is and I cannot make it any simpler than : When I flash the Bootloader into a ATmega2560 using the ISP port and a AVRmkii programmer it flashes no problem but the AT2560 is then unable to accept a a programme via the USB or FTDI ports. This is not the case for the ATmega328 boards all of which accept programmes on the USB Port after flashing the bootloader. The USB and FTDI ports of all the components have been tested and have been proved without doubt to work. jessyjay 356 how about your solution to fixing the bootloader ? Care to share ?

Rgards

John

Sorry again for resurrecting an old thread, but I stumbled upon it while researching the same problem. Solution here, in case anybody else wanders in here.

Cheers,
/dev

I think the issues you are having are possibly related to what I have discovered with using the USBasp programmer. This is included below.

With the issues with the Mega2560 that I have discovered when using it with the USBasp ICSP programmer I thought I would try to make several other people’s lives easier but putting the full facts out there. Feel free to correct me if I have things wrong in the summary below.

This issue with the Mega 2560 and the USBasp programmer connected to the ICSP port has got unfortunately three facets to it which I will go over below.

BACKGROUND
The first is that the Mega 2560 with 256KB is the only AVR micro-controller that I am aware of in common use that exceeds the 128KB program size (flash). Most other micro-controllers are in the program size (flash) range of 8-32KB.

ISSUE 1 – NEW ISSUE CAUSED BY LARGE FLASH SIZE OF MEGA 2560
The first issue relates to the operation of the ICSP port on the Mega2560 (not the ICSP port for the 8U2 or 16U2 micro-controller for USB<->Serial comms). The issue here is that the ICSP protocol uses two functions to set the address:

1. The Load Program Memory Page (LPMP) which takes a 16 bit address (ie. 0x0000 – 0xFFFF).

2. The Load Extended Address Byte (LEAB) which deals with addresses that exceed what 1) can handle. This sets the part of the address higher than the 16 bits allowed in LPMP.

For most processors the LEAB is not needed as the address fits within the LPMP range. The address of 0xFFFF corresponds to the 64KB boundary but because this is a WORD address (not BYTE address) the actual memory range LPMP handles is therefore 128KB. A byte is 8bits and a word is 16bits.

TAKEHOME MESSAGE:
The take home message is that the Mega 2560 needs to use the Load Extended Address Byte (LEAB) function to access all of memory correctly. Any programmer using the ICSP interface MUST implement the LEAB function correctly. This will not be an issue for any other AVR micro-controller that has less than 128KB of flash, eeprom etc. Most other micro-controllers do not have more than 128KB of program space (flash).

ISSUE 2 – THOMAS FISCHL FIRMWARE ISSUE
While there are several USBasp programmers made from different companies they largely operate off firmware from Thomas Fischl who looks to be a German chap. The second problem comes to a head with firmware V1.04 (usually dated as being 28 May 2011 version). This firmware purports to support Mega2560 extended address space but has a bug that causes another set of issues.

In summary the issues are:

a) PART A OF ISSUE 2 (HFUSE IS 0xD8)
If the hfuse of Mega2560 is set to 0xD8 then it will be possible to program the second half of the flash address space (corresponds to byte addresses from 0x20000 to 0x3FFFF). The fuse setting for the Mega2560 typically has the bootloader located at word address 0x1F000. This corresponds to byte address 0x3E000. This means the normal fuse setting of hfuse=0xD8 allows the bootloader to be burnt to flash. In fact it will also burn the bootloader at address 0x1E000 as well but it will never get run from there. This burning at 0x1E000 is pointless but is an issue related to not handling the 0x3 part of the address correctly.

b) PART B OF ISSUE 2 (HFUSE IS 0xD9)
The other scenario you get is if the hfuse is set to 0xD9. This will not execute the bootloader but instead immediately executes the users application. When this fuse is set it will be possible to correctly program the lower address space (bottom 128KB) but the top 128KB will just be a copy of the lower address space - the users program will be loaded a second time at an address that will not be used – like the situation with PART A ISSUE 2. The users program will basically be loaded at address 0x00000 and will also be loaded at 0x20000 (start of second 128KB of flash).
A related issue here is that I purchased my USBasp from Jaycar in 2018 and despite being well after the V1.04 firmware creation date in 2011 it still had V1.02 on it. Even though I upgraded it to the latest version (V1.04) the bug I have just documented here as issue 2 then raised its head.

TAKEHOME MESSAGE:
So even if you do the upgrade to USBasp V1.04 from Thomas Fischl you are stuffed if you are wanting to load both the bootloader AND your application into flash – or make a complete copy of flash in the Mega2560. In my case I wanted to make a full backup of the Mega2560 and that was also not possible. The file that is created has had no errors flagged in the process but it will not work if you use it to reload your Mega2560 and you want the bootloader AND your sketch (application) loaded back again.
The command to dump what is in flash should be (from cmd prompt):

avrdude -p m2560 -c usbasp -C -Uflash:r:flashbackup:r

but if written back to flash with hfuse = 0xD8 the bootloader will be there but not your application (sketch):
avrdude -p m2560 -c usbasp -C -Uflash:w:flashbackup:r
You need to download a version of the firmware which properly works with the Mega2560 and this one appears to do just this:

ISSUE 3 – USING AVRDUDE WITH -p wiring HAS TIMEOUT ISSUES
The last issue is that I thought given the Arduino IDE uses the wiring interface to program the sketches into the Arduino, and this works, could I bypass the USBasp programmer and just use the AtMega16U2 USB to Serial chip to do what I want. After all this is how the Arduino IDE uploads my sketches.

The answer is no – well not in terminal mode. When using avrdude to connect to the Mega2560 I ran it from a cmd prompt as follows:
avrdude -p m2560 -c wiring -C -B 19200 -P COM4 -t

With my limited understanding I would have thought this would have worked. Unfortunately reading the fuses was only partially successful and reading flash or eeprom was always unsuccessful:

in avrdude:
avrdude> dump flash 0 300 - FAILS
avrdude> dump eeprom 0 300 – FAILS
avrdude> dump hfuse or dump efuse etc – PARTIALLY SUCCESSFUL

When the -t switch is used with wiring because it talks via the Mega16U2 chip there is a timeout built into the firmware on this chip that largely makes using this method hopeless. It will timeout before the user generally enters too many commands.
You can use to wiring interface to dump the flash out:
avrdude -p m2560 -c wiring -C -B 19200 -P COM4 -Uflash:r:flashbackup.bin:r
because there is no delay waiting for the user to enter the command but unless you know about this timeout preventing -t (interactive terminal mode) from working you are stuffed again.

TAKEHOME MESSAGE:
The wiring interface which is what the Arduino IDE defaults to will work with the Mega2560 but unless you avoid terminal mode your mileage will vary. For the beginner in AVR & Arduino there are limitations which preclude the use of terminal mode as a second option to doing basic things like dumping flash or eeprom when using the USBasp programmer. Your output will show all 0x00’s which is crap. You will also get the occasional stk500_v2 error. When the USBasp programmer is connected instead the avrdude terminal mode there is no timeout issue.

Overall a painful learning experience and one that I hope may help you.