Do not buy the mega 2560 until gcc is fixed!!

I have discovered that gcc since 4.4 has a fatal defect - it cannot handle multiple C++ initialisers (register R20 is corrupted). See XXXXXXXXXXX Furthermore there is a second bug that makes half the memory unusable - see XXXXXXXXXX

Gcc 4.3.5 does not have the R20 bug, BUT it will not compile for the 2560, only the original mega(1280).

Can the arduino supplier please tell us which version of gcc will allow a Mega2560 to run the LiquidCrystal HelloWorld and Serial ASCIITable examples - I believe the Mega2560 is currently useless for any non-trivial program. The mega(1280) with 4.3.5 will run these two examples, but not with later versions

(I have, of course, got links to these bugs in places of XXXXX, but this forum won't accept links. Afraid you'll have to google them as I did)


but this forum won't accept links

It will, now that you've made one post.

I have, of course, got links to these bugs in places of XXXXX, but this forum won't accept links. Afraid you'll have to google them as I did

Interesting; I have known about this issue for several months now - mainly thru reading others posts on this forum. Its a shame that you just found out about this. I presume you are upset because you purchased or built such a board with the 2560 and now you can't get it work?

The Arduino IDE ships with GCC 4.3.2 (at least on the Mac).

4.3.2 does not have the C++ bug (4.5.1 does) and does work with the 2560.

You do have to change the eeprom.h file

refer to Bootloader for Arduino Mega2560

I have confirmed that the size problem only shows up when the data space is over 64K.

info.MANUFACTURER = Arduino
info.CPU-NAME = ATmega2560
info.GCC-Version = 4.3.2
info.AVR-LibC-Ver = 1.6.4
info.Compiled-date = Nov 2 2010
info.Test-Suite-Name = general


I am now really puzzled... I am using arduino-0021, and my eeprom.h is really different - the $Id line is /* $Id: eeprom.h 2111 2010-03-28 22:36:13Z arcanum $ */

I haven't replaced it yet. Very simple LED blink programs run fine, so I am communicating with the mega2560

I have gcc-config'd to 4.3.5, and I get

unknown MCU 'atmega2560' specified

when I set the board type to atmega2560 and compile Using strace I identified where:

avr-gcc claims that atmega2560 is supported

/usr/libexec/gcc/avr/4.3.5/cc1 DOES NOT support it - it only goes as far as the 1284.

I checked -- version, and it really is cc1 4.3.5 p1.1. I looked at my other versions, and cc1 for 4.4.4 and 4.5.1 do support the 2560, 4.2.4 does not

Can you confirm which arduino you use, and that your cc1 really is 4.3.2. It seems odd that support was lost from 4.3.2 to 4.3.5, but it could be.

Cr0sh. I am upset because I've had really good experiences with the 328 based arduinos. I needed 3 hardware serials, so the mega was ideal. I choose the 2560 as it was not more expensive, and the 8u2 might be useful.

I had not realised that avr effort in gcc is so limited, with bugs unfixed for several years. It would pay atmel to support gcc - I am now having to consider the mbed platform just to get a reliable tool chain.

I note that atmel's tool chain version 2.4.2 uses a possibly hacked version of 4.3.2. I might try downloading that, and seeing if it will compile for the 2560. (Gentoo does not have 4.3.2, only 4.3.3 and 4.3.5 in the 4.3 series)

Fortunately I have one mega(1280) on hand - I just don't want to have to explain to the boss that 4 mega2560s he's bought are only paperweights for the time being...

Back to hacking...

wombat42: what operating system are you on? It may be that the ATmega2560 support on Mac and Windows was provided through additional patches as part of the WinAVR and CrossPack distributions, but it should work on both those platforms. It also works on my Ubuntu 9.04, but I haven't tested other Linux distributions.

I use Gentoo - so I get to choose the avr-gcc version etc. :slight_smile:

I may just have a problem with a mis-configured gcc. Building cross compilers is legendarily difficult. Could you confirm

-which avr-gcc version you’re using

-that the asciitable example runs on your mega2560 and shows up in the serial monitor on your ubuntu system

  • if you run
    /usr/libexec/gcc/avr/4.3.5/cc1 -mmcu=atmega2560 < /dev/null

do you get an error message? - for me 1280 is ok, 2560 reports error. (You will need to change the path to find your avr cc1)

Thanks - I really want to get the 2560 working, it’s just so new that there are few other Linux users I fear :sunglasses:

There is a fix and a workaround for the constructor problems. Read about it here.

On the Mac, I’m using avr-gcc 4.3.3, which supports the ATmega1280 and ATmega2560:

Mellis:~ mellis$ /usr/local/CrossPack-AVR-20100115/libexec/gcc/avr/4.3.3/cc1 -mmcu=atmega1280 < /dev/null

Execution times (seconds)
 TOTAL                 :   0.00             0.00             0.01                477 kB
Mellis:~ mellis$ /usr/local/CrossPack-AVR-20100115/libexec/gcc/avr/4.3.3/cc1 -mmcu=atmega2560 < /dev/null

Execution times (seconds)
 TOTAL                 :   0.00             0.00             0.01                477 kB

Andy Brown

Great work - gentoo applies the patch really easily. I'm still thinking about the linker script question, but the workaround is good


I now realise that the Linux and Windows/Mac toolchains have diverged. avr-gcc 4.3.3 built on gentoo just does not have support for the 2560 in the source code

With the patch, I thought I'd try 4.5.1, which does have 2560. No go - avr-libc 1.7.0 does not support the 2560. Apparently there is an unofficial patch to create support for the avr6 processors - I'm now looking for it!

Does anyone know where WinAVR list their patch set - some will be Windows specific, but it would give us Linux users a start :-/

I thought I'd try 4.5.1, which does have 2560. No go - avr-libc 1.7.0 does not support the 2560.

Really? I downloaded 4.5.1 and 1.7.0 direct from and it does include 2560 support...

grep 2560 /Downloads/avr-libc-1.7.0/avr/lib/avr6/*
/Downloads/avr-libc-1.7.0/avr/lib/avr6/Makefile:am__append_1 = atmega2560
/Downloads/avr-libc-1.7.0/avr/lib/avr6/Makefile:SUBDIRS = atmega2560 atmega2561
/Downloads/avr-libc-1.7.0/avr/lib/avr6/ =  atmega2560 atmega2561
/Downloads/avr-libc-1.7.0/avr/lib/avr6/ HAS_atmega2560
/Downloads/avr-libc-1.7.0/avr/lib/avr6/  AVRLIB_DEVLIST += atmega2560
/Downloads/avr-libc-1.7.0/avr/lib/avr6/        # atmega2560
/Downloads/avr-libc-1.7.0/avr/lib/avr6/ = atmega2560


you are correct, but the path to success was slightly hidden for me...

I use gentoo, which has a useful script called crossdev that builds a cross compiler toolchain. I had gone back to 4.3.3 to see if it avoided the constructor bug.

What I didn't realise is that avr-libc configures its list of supported processors based on the gcc used to compile it, and that when I gcc-config'd to 4.5.1 it didn't switch to libc compiled by 4.5.1

In case there are any other Gentoo people out there with mega2560s:

remove avr-gcc and avr-libc (using emerge -C)

edit the avr-gcc 4.5.1 ebuild to incorporate patch from

USE="-openmp" crossdev -t avr --l 1.7.0 --g 4.5.1 -s4

Now asciitable runs 8-) I'm now hitting the bug with download often failing - looks like it doesn't like sketches which send lots of serial data straight after reset However, that's for a different topic...

Thanks for all the help :D

I didn’t realise is that avr-libc configures its list of supported processors based on the gcc used to compile it

Ahh. Sneaky! All this automatic configuration and makefile creation stuff is just great when it works, but when it doesn’t work it gets VERY hard to figure out what is going on…

Thanks for the followup explanation…

Has the Arduino IDE 021 the same problem with the Arduino Mega 2560 ?


Unless 021 has been patched recently - yes it has the problem (on Linux) I had to obtain avr-gcc etc separately - the arduino-0021.tgz file only has the IDE. Windows might be different

If you patch gcc 4.5.1 as described above, compile and install, then build avr-libc WITH THIS COMPILER, and edit your code (and potentially the library too) to put the PROGMEM directive on the constructors, then 0021 seems to work.

The quick test is whether the ASCIITable example works and sends the text back to you.

BEWARE - once ASCIITable is in the mega2560, you'll need around ten attempts to get the next upload to work. I think adding say 5 seconds before it prints anything would help - there's a race condition with the 8U2 'uart' that the FTDI on a plain Mega doesn't show. I thought I'd bricked my mega2560 - you have to time pressing reset and download critically

Have fun ;)