I planned to use an Arduino Mega for an upcoming Circuit Cellar project, but … it doesn’t work. Well, it works, but under very limited circumstances.
The problem manifests itself as a complete crash / lockup under very straightforward conditions: attempting to use the serial output will suffice. This unmodified example sketch fails: AnalogInOutSerial.
After considerable Googling, there’s the showstopper: the gcc-avr compiler fails to save-and-restore a register that gets clobbered by the object constructors. Simple code doesn’t instantiate any objects, so it works fine. The serial failure is just a symptom, which means the various workarounds suggested in the forums don’t fix the general case.
The patch offered for gcc-avr is basically four lines (a pair of save / restores on R20), but requires recompiling what seems to be the entire AVR toolchain from source. That, alas, lies far beyond my capabilities… I could probably figure out enough to recompile it, but I’m very uncertain I could accomplish that without screwing up the main gcc compiler or the setup thereof.
It is not clear to me that the many claims of “it works on this version” are correct. From the nature of the problem, the failures depend critically on addresses occupied, final layout of the program / data in Flash, and (most likely) the execution path. The “working” configurations / systems may simply not fail using the sample programs.
This is on Arch Linux, for what it’s worth, with gcc-avr 4.5.1.
If anybody can walk me through the process of rebuilding whatever must be rebuilt, preferably in a safe place, perhaps I can manually stuff the new file(s) into the proper spots(s) to replace the incorrect ones…
The Smell of Molten Projects in the Morning 
Perhaps you won’t have to. If you look at arduino.cc, you’ll see their “we’re cooking something new for you” page. I suspect they’re going to release 1.0 of their software, which, with luck, might include that little fix. I’m guessing it’ll come out this weekend, but there’s much mystery.
As nearly as I can tell, they just call in the avr-gcc package (or whatever it’s called) as a dependency and use whatever they get…
And that bug is still “unverified” and “unassigned”, so it’ll be while before it trickles down to the distributions and pops out as a routine update.
Follow this link for Building and Installing AVR-GCC under Linux;
http://www.nongnu.org/avr-libc/user-manual/install__tools.html
I’ve followed those instructions anytime I installed Arduino to my Slackware machines. I advise you to use the –prefix= statement as they recommend. They provide links to any necessary libraries (I didn’t need them) and step by step instructions for compiling and installing.
Will do!
I have the sickening suspicion that this could cause dependency hell, because it puts the AVR stuff outside the usual Arch pacman update sequence, but … if it works, I can regard that as collateral damage.
More later…
I can’t speak to Arch but it is not that hard to rebuild the AVR Tool Chain under Linux.
Get the ‘Bingo Script’ at the top of the sticky thread at AVR Freaks gcc forum.
Do not use any version of GCC after 4.3.4 at this time. There were significant changes in the internal logic of GCC when moving to the 4.4/4.5 series that have had little testing of the AVR target, and there are known problems.
Also note that in AVR-LibC 1.7.0 the ‘built-in’ delays in GCC are possibly broken. See the AVR-LibC mailing list, and the patch tracker.
That’s exactly what I don’t want to do: rebuild & patch & update the entire AVR toolchain by myself forever more!
The version of gcc here is 4.5.1 (the current release), so I’d start by backleveling that… and the probability I’d get something wrong with that is essentially 1.00.
One surgical strike to the library seems to have worked around the problem, which is good enough for me!
Myself I’d rather rebuild, Bingo’s script makes it easy, than use a tool chain that I know has problems.