AVR Xplain (xmega eval board), Dragon, and OSX

Year on from my last post. If I don't have nothing worthwhile to say, I don't say anything at all ;->

Or, I've been working on various things, but had nothing to report that would be of use to anyone.

I've been interested for a while in making an xmega based arduino. Double the speed, 12 bit adc's and even dacs. Plus a ton more stuff I can't even start to think about. And cheaper than the equivalent megas. What's not to like.

So, I order an AVR XPlain, a $20 dev board for the xmega128a1 and an AVR Dragon to program it with. BTW Arrow was the only distributor I found selling the xplain at the suggested price. Everyone else seems to want to charge more.

Major joy when it arrives. Major downer when nothing seems to recognize each other.

Using AVR Dragon and Xplain under OSX

The rest of this note describes what you need to do to program an AVR Xplain using an AVR Dragon under OSX.

Unfortunately, I didn't write down the exact error message texts, nor take screen shots as I hit problems along the way ... But it doesn't matter. I was able to get it to work, and will describe
what I needed to do, and what software components you need.

Upgrade the Dragon's firmware

First, you should upgrade the firmware on the Dragon. I'm not sure if this is an optional step, but I strongly recommend you do it. If you are running under OSX, this can be a problem as it requires running avrstudio, which runs on Windows. So you'll either need a Windows box, to dual boot, or a copy of VMware, Parallels, or VirtualBox. While VMWare and Parallels cost some real money, VirtualBox is free. I have VMware, so I downloaded avrstudio, asked it to upgrade, and at about 6 seconds in the progress bar stalled, and 13 seconds in the upgrade failed, complaining that it failed when preparing to write. If you have VMware: go to the VM's USB setting's panel, and uncheck "Automatically connect usb devices". Once that is unchecked, the firmware upgrade worked fine.

Install avrdude 5.8

At first I downloaded AvrCrossPack, formerly AvrMacPack, in order to get access to the whole suite of avr tools. Unfortunately, AvrCrossPack 20090415 includes avrdude 5.6. Which if you try to use with the Dragon and the xmega fails. Badly. I believe it said that the xmega's signature bytes were 000000 not matching the xmega's expected signature bytes. So I tried using -F. No joy, another cryptic, even more cryptic error. After a long hunt, I discovered that 5.6 either has a bug, or for some other reason doesn't support this combination. Fortunately, MacPorts includes avrdude 5.8. Downloaded it, and all works great.

Save the existing flash and fuses

Save the existing flash and fuses so you can restore them later if you screw up. Here's the command line I used:

/opt/local/bin/avrdude -c dragon_jtag -P usb -p x128a1 -U flash:r:xplain.flash:i -U fuse1:r:xplain.fuse1:i -U fuse2:r:xplain.fuse2:i -U fuse3:r:xplain.fuse3:i -U fuse4:r:xplain.fuse4:i -U fuse5:r:xplain.fuse5:i -U lock:r:xplain.lock:i

After upgrading the Dragon and getting the right rev of avrdude, this worked fantastic!

Play!

After all that, now it's time to play with this beast. First up, write an arduino compatible bootloader, probably starting with Arduino's existing STK500 based bootloader.

Sanguino burn bootloader script

So, got a script that will burn a bootloader from the command line, taking the clock speed as an option.

cat <burn.sh
# For example: sh burn.sh 8
sudo avrdude \
-c avrisp2 \
-P usb \
-p m644\
-e \
-U lock:w:0x3F:m \
-U efuse:w:0xFD:m \
-U hfuse:w:0xDC:m \
-U lfuse:w:0xFF:m \
-B $1
sudo avrdude \
-c avrisp2 \
-P usb \
-p m644\
-e \
-U flash:w:arduino-0012/hardware/bootloaders/atmega644/ATmegaBOOT_644.hex:i \
-U lock:w:0x0F:m \
DONE

Fixing device signature = 0x000000

Summary:

Use AVRDUDE with "-B 8" to write the arduino bootloader of your choice. Then use arduino to do it again.

Details:

Last post was about discovering that I couldn't write a bootloader to a bunch of atmega 644's from the arduino ide. Ditto using avrdude. Indeed, trying to do anything using avrdude resulted in the message:

avrdude: Device signature = 0x000000
avrdude: Expected signature for ATMEGA644 is 1E 96 09
Double check chip, or use -F to override this check.

Turns out that AVR ships many chips with a slow clock speed. So avrdude has to be told to chill out a bit ;->Which can be done by using "-B DELAY" to slow avrdude's clock speed. One of my chips respond with DELAY set to 4. Another 6. Others may require even larger settings. We'll see.

Burning a bootloader using avrdude with "-B 6" seems to change the clock speed on the chip, so that "-B DELAY" is no longer needed, so that bootloaders can now be written from the arduino IDE. But the bootloader loaded using avrdude doesn't seem to interact with the arduino IDE correctly. So, go to the arduino IDE, and burn the bootloader again.

Now all should be well, and you should be able to download sketches to the chip over the serial line.

Clearly, what's happened is downloading using avrdude set the chips clock bits, but did not use the right flags to download the bootloader correctly. With the clock running quickly enough, the arduino IDE uses the correct avrdude options to download the bootloader. I could figure out the right flags and do it in one shot. And probably will. But for now, this is good enough to make my chips useful.

Not dead, just mostly dead

So, to work on my breadboard Sanguino, I needed some Atmega644P's. They were on back order everywhere, and the Sanguino zip files seemed to suggest that it also worked with Atmega644's. Something like $7+ quantity 1, $5 quantity 25. So I got 25 from mouser.

After building the breadboard I needed to download the bootloader. Connected my AvrISPmkII. And ... first chip wouldn't take it - got some weird error from avrdude (more later). Second chip worked like a charm. Ditto third. I figured I'd fried the first chip. Later, I tried to burn the bootloader on the remaining chips. All got the same error:


sudo avrdude -p m644 -c avrisp2 -P usb

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x000000
avrdude: Expected signature for ATMEGA644 is 1E 96 09
Double check chip, or use -F to override this check.

avrdude done. Thank you.


Now, no way did I fry all them chips. Nor could they all be bad, maybe it was a glitch on the bread board? But that didn't make sense, what about them two good 644's that were working just fine ... So I ignored it for the time being.

So, I finished my PCB design, sent it in to golden phoenix PCB - yet another suggestion from Zack (thanks Zack!) - and got it back a week later. Arrived on my doorstep a matter of hours after I left to visit my family for a week. Argh! So I got back late Sunday, and built the first board Monday figuring that no way could the first board I ever designed work, that $120 was surely down the tubes, but that I'd debug it and the second set of PCBS would work fantastic. WRONG. First board worked right first time out.

So I decided to burn the bootloader on the rest of my chips. Again, no go, device signature was 000000. On the 23 remaining chips. Every single one dead.

Hmm, but that doesn't make sense. While a bread board might be electrically wonky, I was now pretty sure my PCB was pretty solid. And I couldn't believe I got 23 dead chips from Mouser. So something weird is afoot.

I poke around on google. Pretty much nothing. Except a hint. Some AT Tinys come from the factory with a slow clock setting, and require some other programmer to set a jumper to slow down the download clock.

Maybe my chips weren't quite dead. Maybe they were just mostly dead.

Now the AvrMkIspII has no such jumper. And avrdude didn't seem to have any such thing. Till I read the help again:


-B bitclock Specify JTAG/STK500v2 bit clock period (us).
...
-i delay ISP Clock Delay [in microseconds]



Well that looked promising. Didn't know which to try first, so -B it was. BING! It worked. Now on one chip I needed to slow it down to 4us. The next 6us. And once the 644 bootloader is downloaded, it seems to adjust the clock speed, so there's no need for that nonsense any further.

I'm pretty sure the rest of my chips are fine. Just need to play around with the clock speed for each one.

So, while my chips sure seemed dead, as Miracle Max said, mostly dead is not all dead.