Go Down

Topic: Mega 2560 - I can burn bootloader with USBasp, but not sketches (Read 4891 times) previous topic - next topic



I've done a lot of Google'ing before posting here, I'm pretty much out of articles to read at this point. I'm really hoping someone can help.

I've got a Mega 2560 which appears to be semi-bricked. It was working fine, then I tried to write an updated version of my sketch and it failed.

The symptoms were that when powered on, the LED on 13 was lit and did not blink after resetting. The board connects on USB but when trying to program a sketch, the following errors occur (with blink example):

Sketch uses 666 bytes (0%) of program storage space. Maximum is 258,048 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 8,183 bytes for local variables. Maximum is 8,192 bytes.
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer

(This is with 1.5.4 but I get the same issue with 1.0.5)

So I tried burning the bootloader using a USBasp, this seems to work - the IDE finishes and the LED on 13 blinks, I presume because the bootloader also has something like Blink as the default sketch.

However, I still can't program a sketch via USB. If I try programming one via the USBasp, using the "File > Upload Using Programmer" it succeeds, but the sketch does not run/work on the board, I've been trying to write Blink to it but the LED on 13 just remains lit - nothing when reset etc either, not even a short pause before coming back on as you'd usually get.

I'm thinking the board is semi-bricked because it seems to accept the bootloader ok, the fact the LED blinks suggests that. So any ideas why I can't actually burn anything via the USBasp?

I was hoping that it was just the USB (16u2) chip that had failed and I could carry on using the board with an ISP... but I'm hitting a bit of a brick wall.

I have also tried flashing the 16u2 but wasn't able to, I have followed a couple of tuturuals but keep getting errors in my command window (using Mac OS X Mountain Lion).

Thanks in advance!


Is it an official Mega board ? or a clone from Ebay ?

You are able to program the bootloader but not a sketch with USBasp ?
That doesn't make sense. Perhaps the bootloader was not really programmed or there is perhaps a shortcut on pin 13.

You can try with a led on another pin and upload the sketch with USBasp.

Can you measure the voltages ? The 5V and the 3.3V.
Perhaps it is USB powered and that is too low.

Can you carefully check the board with a magnifier. Perhaps there is a solder dot somewhere.

If the voltages are okay, the board might be broken.


Is your sketch blasting a lot of data out of D0, D1? That can keep the bootloader from starting up. One solution is to press & hold the reset button, release when the IDE shows "Compiled xxx of 256xxx bytes" or similar. May take a few tries to get the timing right.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.


I'll try another pin tomorrow, but USB power is ok and fine programming other boards (incl other Mega's).

It does look like it's not fully programming the bootloader, but then if it's not, why would the LED blink after - that implies it did load it ok, but I still can't put sketches on it.


Bootloader goes in via ICSP, sketches go in via serial D0/D1.
If bootload is failing, I can only recommend getting Atmel AVR ISP MKii to load with.

Here's where I got mine, price has gone ~$3 since spring 2011.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.


I've got one of those on order, official Atmel from RS (in the UK, where I'm from).

I assumed I could program sketches with a USBasp but I will certainly be trying the Atmel one just in case that's the problem. The USBasp is an eBay one, but seems to work for the bootloader anyway.

It's just a bit odd that it works enough for the bootloader (blinking LED) but nothing else.

Thanks for the replies so far.


Well, ebay, who knows what it has for firmware.
Maybe it's not up to speed on programming the larger address space of the 2560.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.


Sorted... it was indeed the programmer.

The Atmel AVR ISP MKII works just fine.

Thanks for your help.


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.

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.

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.

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).

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:

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.

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.

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 <confile file> -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 <config file> -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:

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 <config file location> -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 <config file location> -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.

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.
Geoffrey Brown, Te Puke, New Zealand.


Geoffrey, it is great that you've found all this out but please don't go around necroing every thread on the subject.


Hi BJHenry.

The reason I put the solution against several threads was because in trying to find a solution I came across all these threads (still had them as separate tabs in my browser) and they failed to address the real issues or provided workarounds that were unsatisfactory or useless in other scenarios (like mine).   These workarounds typically allowed only one half of the 256KB flash to be addressed at a time which is still useless in various situations like what I experienced.

The other issue you have here is that these old threads are still fully indexed on search engines like google and unless they are deleted they act as a source of incorrect or poor information for eternity.   The cross posting is therefore to ensure that those web pages I came across trying to find a solution are now corrected for others in the future.   You are otherwise looking for a needle in a haystack trying to find an answer.   I would have had 30+ tabs open trying to figure this issue out.

There is no other purpose or outcome intended by me other than sparing others wasting days with a similar problem.  Unfortunately, I fail to see how others can get the answers they seek amongst a sea of poor information, which is what is currently the state with all the past historic posts. If nothing else readers are aware of the issue and can recognize the issue if using other programmers which are having the same problems.

If you have a solution which provides the correct answer to the multiple past threads that have been started around this problem in the past I am all ears.   What I have done seems to me a sensible thing to do.
Geoffrey Brown, Te Puke, New Zealand.

Go Up