bye, bye, blogspot and blogger. I'm done. I give up...

So I get email from google telling me I need to migrate. They give me the account name I MUST use. I try to log in. Account not recognized. I'm then sent through a rats nest of support pages and log in screens and back to more support pages and blah, Blah, BLAH, !!!!!

So you win google. I'm deleting these accounts. migration issue solved.

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.