Omega's Electronics

(iPhone)

The Xmega has made some major advances in clock management, likely as a conceptual follow-on to the picoPower AVR. While clock selection used to be both limited to a few options and mostly configured via fuses (at programming time), the Xmega has a very wide range of clocking choices that are entirely run-time configured.

The Xmega has the following clock sources available:

- 2MHz internal RC
- 32MHz internal ring oscillator
- 32.768 internal precision RC
- 400kHz – 20MHz external crystal
- 32.768 external crystal
- External (square wave) clock

In addition there are not only the usual clock dividers, but a PLL capable of anywhere from 2x to 31x multiplication.

All chips power up off the 2MHz internal RC at all times, because it’s the first to come up and is guaranteed to be available. All user code that wishes to use something else must configure it before continuing.

Each clock source has both an enable bit and a ready flag, since various clocks take different (and sometimes relatively long) periods of time to stabilize. The external crystal drivers also have failure detectors with dedicated interrupts that fire after the clock is switched back to the 2MHz fallback.

Several of the key registers are covered by the Configuration Change Protection (CCP) mechanism, which is nearly identical to the mechanism used to change or disable the watchdog timer on conventional AVRs. To write the protected register one must first write the CCP register, then the desired register within some short number of cycles (typically 4). This is to protect mostly from rogue memory pointers drifting into critical registers.

There are a total of 3 dividers, which allow the clock to be dropped by as much as 4096(?)x from the base frequency, in powers of 2. However, the first two have more specific purpose: they allow higher peripheral clocks to specific modules. CLKper4 and CLKper2 drive the high-res timer and External Bus Interface modules, respectively.

To make use of these higher frequencies, the (???) register can be set to predivide the input clock in order to bring it down to the range in which the actual CPU can operate. For instance: 8MHz crystal with 16x PLL gives 128MHz, which when divided /2,/2, gives 32MHz to the CPU, 64MHz to the EBI, and 128MHz to the highres timer extention.

Additionally for those who need the lower parts count you get from running off one of the internal oscillators, the Xmega theoretically offers two DFLL’s (Digital Frequency-Locked Loop) that are supposed to adjust the timings (a la OSCCAL) relative to a 32.768kHz reference, either internal or external. However, this module appears to be particularly buggy, and for the most part can be treated as if it doesn’t exist, at least in current silicon.

I will be posting a form of my clock routines sometime tomorrow to help get people boot-strapped on something other than ~2MHz…

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

(first edit of iPhone version)

Once you have the required programming hardware for your Xmega, you need to figure out how to actually use it to load your code.  You can’t just shove it at the programmer and hope it does something intelligent (though that would be nice), you have to talk the particular language of each programmer.  At least for the Atmel programmers there’s one main protocol (STK500[v2]), but there are so many variations even within that one protocol as to make anybody’s head spin.  Luckily, that’s why people write programming tools: to hide the (sometimes unnecessary) complexity of the programming hardware.

Right off the bat, I’ll list the default AVRStudio as the most integrated solution. However, that’s about all I can tell you, since I only use it for reference and recovery when I run into problems or complications with my usual method. Hopefully somebody who already uses it or learns how can post further details, which I can fold into this tutorial if desired.

AVRDude is the other major piece of software, and the only one I use to actually load code. It’s an open-source tool capable of using any of several dozen types of programming hardware to flash most every AVR out there (and then some). It works best on Unix-style systems (Linux, Mac) but presumably runs just fine on Windows as well, as it’s packaged with the Win-AVR bundle.

When I put projects together, I typically start with a simple shell script that compiles, preps and downloads the firmware in one go. This is somewhat peculiar to my work patterns as I don’t use an IDE of any sort (not even emacs).  Makefiles are the more common but also somewhat more involved method.  Most projects I create that use more than one source file are implemented with Make, but more on that later.

The actual command to flash the chip is something along the lines of:

avrdude -pavrisp2 -Pusb -cx192a3 -U w:flash:myprog.srec

The -p argument sets the programming tool to be used, and -P tells avrdude which port to use.  usb is the connection method for all of the currently available Xmega-compatible programmers, though my current project uses a bootloader that implements the avr910 protocol over a standard serial port, e.g. /dev/ttyUSB0.  The chip being programmed is given by the -c, and -U specifies an upload operation, in this case writing to flash the contents of myprog.srec.

(first update pass of iPhone-written draft)

Atmel’s new AVR Xmega chips use a new programming interface called PDI (Program and Debug Interface) that has both advantages and disadvantages vs. the older ISP protocol used by the original AVR series. The main advantages are the reduced pin count, and the use of the same 2×3 pin connector (if you’re confused, read on…). The disadvantage is that it’s a new protocol that isn’t quite as well supported yet.

While the old ISP protocol is basically SPI with the chip-select line driving RESET, for a total of 6 lines (GND, VCC, SS/RESET, SCK, MISO, MOSI), the PDI protocol is bidirectional synchronous serial, using only 4: GND, VCC, CLK, DATA. This reduction in pin count has two advantages: the number of pins used on the actual chip is lower, and custom programming interconnects can get smaller. The main effect of this on the Xmega is that the PDI lines are strictly dedicated to programming: no more carefully sharing the SPI bus with your real peripheral[s]!

Now back to the part about it being the same old connector: Atmel realized that everybody had developed a significant, um, “attachment” to both their existing programming tools and the connector itself (as opposed to say JTAG’s varied and invariably larger pinouts), and forcing everybody to buy brand new tools just wasn’t going to happen. They also determined that the bidirectional bus of PDI could be effectively implemented by some of their “older” tools!

As a result, they did something that seems far too rare in any industry: add new functionality to already-sold hardware by enhancing the firmware. Duh! you say, but you’d be surprised how often it doesn’t happen.

The gist of this all is that for the most part, any of Atmel’s tools in the last several years have been updated to program the Xmega’s. Off the top of my head (while sitting on a ferry…) at least these programmers are supposed to work:

- AVR-ISP MkII
- Dragon
- JTAG ICE MkII

All these programmers use the STK500 protocol with an “XPROG” extended mode, which grants access to all the newer memory (flash) regions of the Xmega chips.

I haven’t particularly looked for any third-party support for the PDI protocol in other programmers, so at this point you’re mostly stuck with the above devices.  However, the AVR-ISP MkII isn’t really all that expensive, running $35.36 from Digikey.  While I applaud people who design their own bootstrap programmers and such, I really never got the obsessive need to spend so much effort to save a Jackson or two.  I know how much work it takes to implement a programmer like this, because I’ve been required to do so for some commercial projects.  I’m writing one right now as it turns out…  Development effort can run into the $1000′s if you value your time at all.

That being said, I am going to be writing my own PDI stack in the near future, because of the requirements of a commercial project very similar to the one that had me writing such code last time.  It will be released to the public in a form that I believe will be far more modular and easy to integrate into other software projects.  More on that later.