Getting started with Xmega: toolchain


(first edit of iPhone version)

Another major advantage of the Xmega is the fact that it is running the exact same CPU core as the original AVR, which means the toolchain is almost exactly the same. The only major things new to these chips are the linker scripts (since flash addresses are different) and the header files that define the registers for the various peripherals.  However, it is still the case that if your toolchain doesn’t have the necessary changes and is thus aware of the particular chips you’re using, you’re sunk.  The situation is still somewhat inconsistent enough that you may end up with a few challenges between you and writing code for the Xmega.

GCC is the default compiler in the open-source world, and it has been made to work with the AVR even though it’s not strictly the right kind of processor (GCC dislikes Harvard-architecture chips as a rule).  The avr-gcc project maintains the patches necessary to compile for AVR chips, and thus is responsible for managing the patches that make the Xmega work as well.  The current problem is that the various distributors of avr-gcc are responsible for actually bringing those patches into their builds of the software, and that’s where the breakdown is right now.  avr-gcc is in the process of getting their patches folded into the GCC mainline, which will eliminate the problem, but that could still be in the works in 2011…

Xmega support was initially added back when the silicon was still a glimmer in the hobbyists’ eye, and began in earnest when early silicon was delivered to select developers (to te best of my knowledge). As such, full support of the whole range of devices took a little while to fully materialize.  The current set of patches (as of roughly early June 2010) finally contains support for all the Xmega devices Atmel has actually physically shipped, plus a few extras still in the pipeline or available only in select (export) markets.

The Win-AVR bundle, which has recently been discontinued in anticipation of upgrades to AVRStudio, was generally the most up-to-date toolchain you can get.  The “most official” place to get patches would be either the Win-AVR site, or the FreeBSD repository, seemingly dependent on the weather.  Folding into GCC mainline will resolve that problem, but Win-AVR is still the “easiest” place to find what you need.

Unfortunately, distributions like Ubuntu (and its underlying Debian) haven’t been as careful in updating.  The Ubuntu 10.04 avr-gcc packages are no different than the year-old 9.04 packages, and thus contain only small fragments of Xmega support.  A number of scripts and other documents are out there that purport to solve the problem, but the several that I’ve looked at have the same problem of having been inconsistently updated.  As a result it took me longer than it should have to piece together a toolchain for my machine.  I will be posting the .deb’s of those packages in the near future, hopefully before the Open Lab on June 27th.



  1. Hey, thanks so much for your posts on atxmega development with a proper unix, I’ve been getting fed up with winavr as a dev environment so this is great. I was wondering if you could share where you are getting your patches from? I’m having issues with the patches from winavr and can’t seem to find a set of patches that builds fully – (I’m on OSX/gentoo for my build systems so I don’t have .deb installers).

    • Unfortunately that’s a hard question to answer, as even the developers don’t seem to know. WinAVR is being deprecated, though I hear rumblings from the maintainer that he’s being pressured to keep it going. Nominally the new AVR Studio is supposed to take over, as it uses the GNU toolchain, but that doesn’t really help with running the toolchain elsewhere. Everybody seems to agree that all the various AVR patches need to be pushed up into binutils and gcc mainline, but it doesn’t ever seem to happen, for reasons that escape me and just about everybody else.

      It seems to me at this point that there is no official repository for patches, which I consider to be an unacceptable situation. Whenever the question is raised on the mailing lists, I have seen answers that don’t even pretend to be useful. There’s a discussion on avr-gcc-list currently about somebody creating yet another toolchain builder script. His initial list of references included something like 8 other such projects, and all of them are of different versions and contain different set of patches.

      The best lead I’ve come up with from that thread is to look for “Bingo6000″s script, which downloads various patches and builds the tools. At some point I’ll have to look at those myself, but for now I have a running toolchain and a deadline ;-) Let me know what happens, maybe I/we can post something here with more detail.

  2. Just wanted to share my notes on the build process now that I’ve got a working toolchain under darwin. I essentially worked off of the free-bsd archives, but heres a quick couple of notes for those who want to do it:

    for the purpose of this, I have set PREFIX=~/local/avr
    Your path needs $PREFIX/bin added to it

    I had gmp installed with macports – hence the –with-gmp=/opt/local flag

    On darwin I had to edit /gcc/cp/Make-lang.in to remove tree-inline.o from the object list (Xcode linker craps out otherwise)

    for each one of these patch sets, download the entire directory as a tarball, move the files into a subdirectory of the source directory called patches. Make a shell script in the program source root called patchscript.sh with the following:

    for PATCH in `ls patches/patch-*`
    patch -p0 < $PATCH

    The following is the notes I have for each package:

    patches from: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/
    configured with: ../configure –prefix=$PREFIX –target=avr –disable-nls –program-prefix=avr-

    patches from: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-gcc/files/
    configured with: ../configure –prefix=$PREFIX –target=avr –enable-languages=c,c++ –disable-nls –disable-libssp –with-dwarf2 –with-gmp=/opt/local –program-prefix=avr

    After install create avr-gcc symlink (installs as avr-gcc-4.3.4)

    configured with: ./configure –prefix=$PREFIX –build=`./config.guess` –host=avr

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: