Getting Started with USB DFU

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, I recently got one of the Copper boards from http://store.stackfoundry.com/de...

And, it has the USB DFU (along with the DFU button).

My platform is Ubuntu 9.10 and I got all of the AVR tools installed (compiler and the like). I tried AVR Studio a go, but I definitely prefer my good ole' makefiles.

I really want to use the USB DFU to program my device as in its final casing, it would be very difficult to get any programming cables in. Also, I am very used to debugging via blinking LEDs and wouldn't be able to use any sort of device debugger anyway.

There's three big questions:

1) The suggested code compilation that AVRStudio tries to go with is:

# avr32-gcc -O2 -Wall -c -fmessage-length=0 -mpart=uc3b1256 -ffunction-sections -masm-addr-pseudos -ohello2.o ../hello2.c
# avr32-gcc -mpart=uc3b1256 -Wl,--gc-sections --rodata-writable -Wl,--direct-data -ohello2.elf hello2.o

I then convert it to intel hex...

# avr32-objcopy -O ihex hello2.elf hello2.hex

Then, I try burning it...

# sudo dfu-programmer at32uc3b1256 flash hello2.hex
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore

This warning message scares me... a LOT. I read a lot and people were telling other people to relocate things to 0x80002000 and whatnot. Do I need to do this? Can I accomplish this with --change-section-vma? do I need to modify linker scripts that are inside of the AVR toolchain?

Bigger deal is I jut want to make sure whatever I do, I don't blow away the DFU bootloader.

#2: When programming my device with firmware that uses USB, is there any risk of blowing away my DFU bootloader?

Thanks!! Charles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm pretty sure 0x80002000 is the "after the bootloader" address. Writing before it will overwrite said bootloader (this address might be different if you're using a different bootloader.)

When programming via USB it is the bootloader which makes this possible--not sure if it can be accidentally overwritten this way or not (though one can easily add/remove the bootloader with a JTAG--I have one; despite my debugging experience and methodology being exactly like yours.)

Lastly, external interface from a JTAG is the only thing which can save your uC if something HAS happened to your bootloader.

Hope this helps.

Elect reputable scientists!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR32784 says:

Quote:
An AT32UC3 part having the bootloader programmed resets as any other part at 80000000h.
Bootloader execution begins here. The bootloader first performs the boot process to know
whether it should start the USB DFU ISP or the application. If the tested conditions indicate that
the USB DFU ISP should be started, then execution continues in the bootloader area, i.e.
between 80000000h and 80002000h, else the bootloader launches the application at
80002000h.

So, it leads me to believe I am pretty sure I want to write at 80002000h. If possible, I still want to avoid having to purchase a JTAG programmer. I guess if someone who has a project working with the DFU uploader can post the command-line steps that would be useful?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

*sigh*
While the JTAG is expensive (like, holy-jeezus it costs how much?!) the capabilities are incredibly worthwhile. Honestly, were it not for my boss supplying me with one, I wouldn't have one either.

That being said. there are low-cost alternatives which provide the same functionality. I would urge you to examine the possibility of adopting one. Here's one such example http://www.ladyada.net/make/usbtinyisp/ which cost a fraction of a percent of what a JTAG-ICE MKII does. And that one is simply one among many.

Elect reputable scientists!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've actually used the tinyisp's extensively with the Tiny's and Mega's I've used. I seem to recall looking at the pin out for the JTAG connector and seeing that it had very little in common with the tinyisp's 10-pin SPI header.

Regardless - even if I were to purchase a JTAG kit, I would still need a way (eventually) to program the device via DFU so I don't have to try to jam a JTAG to the outside of the case.

Is it that uncommon for people to use these things by DFU? - and even less common to use them with dfu-programmer?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm really not sure if you understand your problem. The code you want to program and the bootloader overlaps - the BL is located at 0x800000000-0x800002000. So what? either you code is linked at 0x800000000 with a trampoline (size 2000h) that will _not_ be programmed {and you'll have the warning message}, or link your code at 0x800002000 without trampoline. Solution 1 makes the code works if you load it with jtag, solution 2 does not.

-sma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alternately, there's a bootloader which can program the unit from a USB drive. uC acts as host and (under the right conditions) reads new program from USB. I've been tinkering with it--hopefully to make all my devices easily field-updateable in the future.

Elect reputable scientists!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sma wrote:
I'm really not sure if you understand your problem. The code you want to program and the bootloader overlaps - the BL is located at 0x800000000-0x800002000. So what? either you code is linked at 0x800000000 with a trampoline (size 2000h) that will _not_ be programmed {and you'll have the warning message}, or link your code at 0x800002000 without trampoline. Solution 1 makes the code works if you load it with jtag, solution 2 does not.

-sma

The trampoline solution is exactly what I'm going for. I got my hands on a BlinkingLights.rar that I found last weekend, however I have since lost the link. I know it was somewhere on this forum. Even this demo doesn't seem to produce the right behavior.

I am linking in its trampoline.o (from trampoline.S) If I use the default "-nostartfiles" linker flag, I get a pretty much empty program, if I remove that linker flag, I get a full program, yet it appears to have things in the wrong place...

avr32-objdump presents:

80000000 g     F .reset 00000000 _start
00002290 g     F .const 000000a8 __register_exitproc
00000550 g     O .bss   00000028 __malloc_current_mallinfo
00001000 g       *ABS*  00000000 _stack_size
00000114 g     O .data  00000408 __malloc_av_
0000287c g     F .const 00000002 __malloc_lock
00002afc g     O .const 00000020 __sf_fake_stdin
00000538 g       *ABS*  00000000 __bss_start
000021b8 g     F .const 0000007c main

Note that main() is located PAST 0x2000 after 0. If _start is set correctly (0x8000000) does this mean main is in the correct place as well?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone figured this out yet? I just received my Copper module and thought it would be a breeze to program via DFU, just like my AT90USBKEY. If only there were one, just one, example of how to use the AVR32 GCC toolchain and dfu-programmer to accomplish either of the two scenarios sma describes above, I'd be set.

(How can Atmel write so many pages of documentation and still manage to leave this unclear?)

I built a simple app with

avr32-gcc -c -g -O2 -Wall -ffunction-sections -mpart=uc3a1128 -o hello_world.o hello_world.c
avr32-gcc -g -Wl,--gc-sections -mpart=uc3b1256 -o hello.elf hello.o

and avr32-objdump says "main" is at 0x8000010c. I haven't the foggiest idea how to link this so as to avoid the bootloader, with or without the trampoline. Could a GNU toolchain guru lend a hand?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look in the software framework, projects are linked with trampoline.S (size 2KB) as entry point for the reset vector.

-sma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sma wrote:
Look in the software framework, projects are linked with trampoline.S (size 2KB) as entry point for the reset vector.

I tried building some of the examples in the software framework, but I get the following error consistently:

avr32-gcc (-(Linux-amd64)) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling `../../../../../DRIVERS/INTC/intc.c' to `../../../../../DRIVERS/INTC/intc.o'.
/tmp/ccTef2Zc.s: Assembler messages:
/tmp/ccTef2Zc.s:98: Error: invalid register list `,lr'
/tmp/ccTef2Zc.s:117: Error: invalid register list `,lr'
/tmp/ccTef2Zc.s:162: Error: invalid register list `,pc'
/tmp/ccTef2Zc.s:162: Internal error!
Assertion failure in finish_insn at ../../../binutils-2.19/gas/config/tc-avr32.c line 3417.
Please report this bug.

(This happens for any project/file, including my simple hello.c with a makefile adapted from Atmel's, so I don't think the line numbers are relevant--only the "invalid register list" part.) The only google references are in the context of buildroot. They say the problem is [host] gcc version 4.3. I can't see how that applies here, though. Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had some time this week so came back for another try.

First, I uninstalled all avr32 stuff and libboost dependencies, then reinstalled following the instructions for Ubuntu Karmic in the sticky thread. (I am running Debian Squeeze on amd64.)

I have seen a number of threads where the avr32 assembler complains of "invalid register list `,lr'" or similar. A common answer is to use gcc-4.2 instead of 4.3. But that doesn't work for me (and, judging from the other threads, I am not alone).

I realized that I should be able to look at the offending assembly--just tell gcc to save the temp files. So, here it is:

main:
.LFB2:
        .file 1 "hello.c"
        .loc 1 6 0
        # args = 0, frame = 0, pretend = 0
        # frame_needed = 1, leaf_function = 1
        # uses_anonymous_args = 0
        stm     --sp, , lr

It is complaining about the last line, which indeed looks like a syntax error. On the other hand, I don't know avr32 assembly so I'm not sure. Does the stm instruction allow for empty fields? Maybe it does but my avr32-as doesn't agree on how to express that in assembler?

Can someone comment? This is so aggravating.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Does the stm instruction allow for empty fields?

No (per AVR32 Architecture Document, 32000B, section 8.4).

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting. So my GCC is generating bad assembler. Does anyone know if this necessarily indicates a problem with GCC itself, or could this behavior result from bad configuration somewhere else?

If the former, I'm surprised this has not been discussed elsewhere.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

haunma wrote:
I had some time this week so came back for another try.

First, I uninstalled all avr32 stuff and libboost dependencies, then reinstalled following the instructions for Ubuntu Karmic in the sticky thread. (I am running Debian Squeeze on amd64.)

I have seen a number of threads where the avr32 assembler complains of "invalid register list `,lr'" or similar. A common answer is to use gcc-4.2 instead of 4.3. But that doesn't work for me (and, judging from the other threads, I am not alone).

I realized that I should be able to look at the offending assembly--just tell gcc to save the temp files. So, here it is:

main:
.LFB2:
        .file 1 "hello.c"
        .loc 1 6 0
        # args = 0, frame = 0, pretend = 0
        # frame_needed = 1, leaf_function = 1
        # uses_anonymous_args = 0
        stm     --sp, , lr

It is complaining about the last line, which indeed looks like a syntax error. On the other hand, I don't know avr32 assembly so I'm not sure. Does the stm instruction allow for empty fields? Maybe it does but my avr32-as doesn't agree on how to express that in assembler?

Can someone comment? This is so aggravating.

I have same problem.
Compared to AVR32 GNU Toolchain 2.4.2 - Windows compiler's output, the missing register is r7.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The GCC in "AVR32 GNU Toolchain 2.4.2 - Linux Ubuntu 8.04" package is working properly. Use it instead of version 9.04/9.10 .

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

reggie_ wrote:
The GCC in "AVR32 GNU Toolchain 2.4.2 - Linux Ubuntu 8.04" package is working properly. Use it instead of version 9.04/9.10 .

Hi Reggie,

Thanks, this is valuable info! Before coming back here and seeing your reply, I had a good exchange with some of the Atmel folks on the buildroot mailing list (accessed via avr32linux.org--but I can't give a link right now because the site is down). Their best guess was that this might be an issue with the 64-bit version of avr32-gnu-toolchain. Are you on 64-bit also? And moving back to 2.4.2 solved the problem?

Perhaps this is a recurrence of an earlier bug. The Atmel guys said they had fixed other "invalid register list" problems on 64-bit previously.

hce, if you're reading this, does that sound right? Maybe a useful clue.

Regards,

Mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: I'm still waiting for a resolution to the stm/ldm compiler bug in avr32-gcc. In the meantime, I wanted to get a flashing LED on my Copper dev board to verify that I can program the part by DFU. So, I fixed up the stm/ldm instructions by hand and finished building the elf file.

At this point I'm stuck in the same place as CNLohr, above, without any examples to work with. I did my best to pick the essential pieces out of the Software Framework and include them in my project--not an easy task! I am using the Atmel-supplied trampoline.S (and crt0.S and exception.S). My symbol table looks like this:

SYMBOL TABLE:
80000000 l    d  .reset	00000000 .reset
80002008 l    d  .text	00000000 .text
80002200 l    d  .exception	00000000 .exception
80002400 l    d  .rodata	00000000 .rodata
00000004 l    d  .dalign	00000000 .dalign
00000008 l    d  .bss	00000000 .bss
000000a8 l    d  .heap	00000000 .heap
00000000 l    d  .comment	00000000 .comment
00000000 l    d  .debug_aranges	00000000 .debug_aranges
00000000 l    d  .debug_pubnames	00000000 .debug_pubnames
00000000 l    d  .debug_info	00000000 .debug_info
00000000 l    d  .debug_abbrev	00000000 .debug_abbrev
00000000 l    d  .debug_line	00000000 .debug_line
00000000 l    d  .debug_frame	00000000 .debug_frame
00000000 l    d  .debug_str	00000000 .debug_str
00000000 l    d  .debug_loc	00000000 .debug_loc
00007000 l    d  .stack	00000000 .stack
00000000 l    d  .debug_ranges	00000000 .debug_ranges
80002000 l       .reset	00000000 program_start
00000000 l    df *ABS*	00000000 intc.c
00000008 l     O .bss	00000004 _int_line_handler_table_6
0000000c l     O .bss	00000004 _int_line_handler_table_7
00000010 l     O .bss	00000004 _int_line_handler_table_8
00000014 l     O .bss	00000004 _int_line_handler_table_9
00000018 l     O .bss	00000004 _int_line_handler_table_10
0000001c l     O .bss	00000004 _int_line_handler_table_11
00000020 l     O .bss	00000004 _int_line_handler_table_12
00000024 l     O .bss	00000004 _int_line_handler_table_13
00000028 l     O .bss	0000000c _int_line_handler_table_14
00000034 l     O .bss	00000004 _int_line_handler_table_15
00000038 l     O .bss	00000004 _int_line_handler_table_16
0000003c l     O .bss	00000004 _int_line_handler_table_17
80002400 l     O .rodata	00000090 _int_handler_table
00000040 l     O .bss	00000004 _int_line_handler_table_0
00000044 l     O .bss	0000002c _int_line_handler_table_1
00000070 l     O .bss	00000010 _int_line_handler_table_2
00000080 l     O .bss	0000001c _int_line_handler_table_3
0000009c l     O .bss	00000004 _int_line_handler_table_4
000000a0 l     O .bss	00000004 _int_line_handler_table_5
00000000 l    df *ABS*	00000000 hello.c
800020e4 l       .text	00000000 idata_load_loop_end
800020dc l       .text	00000000 idata_load_loop
800020f6 l       .text	00000000 udata_clear_loop_end
800020f0 l       .text	00000000 udata_clear_loop
80002200 l       .exception	00000000 _handle_Unrecoverable_Exception
80002204 l       .exception	00000000 _handle_TLB_Multiple_Hit
80002208 l       .exception	00000000 _handle_Bus_Error_Data_Fetch
8000220c l       .exception	00000000 _handle_Bus_Error_Instruction_Fetch
80002210 l       .exception	00000000 _handle_NMI
80002214 l       .exception	00000000 _handle_Instruction_Address
80002218 l       .exception	00000000 _handle_ITLB_Protection
8000221c l       .exception	00000000 _handle_Breakpoint
80002220 l       .exception	00000000 _handle_Illegal_Opcode
80002224 l       .exception	00000000 _handle_Unimplemented_Instruction
80002228 l       .exception	00000000 _handle_Privilege_Violation
8000222c l       .exception	00000000 _handle_Floating_Point
80002230 l       .exception	00000000 _handle_Coprocessor_Absent
80002234 l       .exception	00000000 _handle_Data_Address_Read
80002238 l       .exception	00000000 _handle_Data_Address_Write
8000223c l       .exception	00000000 _handle_DTLB_Protection_Read
80002240 l       .exception	00000000 _handle_DTLB_Protection_Write
80002244 l       .exception	00000000 _handle_DTLB_Modified
80002250 l       .exception	00000000 _handle_ITLB_Miss
80002260 l       .exception	00000000 _handle_DTLB_Miss_Read
80002270 l       .exception	00000000 _handle_DTLB_Miss_Write
80002300 l       .exception	00000000 _handle_Supervisor_Call
80002304 l       .exception	00000000 _int0
80002312 l       .exception	00000000 _int1
80002320 l       .exception	00000000 _int2
8000232e l       .exception	00000000 _int3
00007000 g       *ABS*	00000000 __heap_end__
80002200 g     F .exception	00000000 _evba
ffffffff g       *ABS*	00000000 __heap_size__
80000000 g     F .reset	00000000 _trampoline
00001000 g       *ABS*	00000000 _stack_size
00000008 g       *ABS*	00000000 __bss_start
80002040 g     F .text	0000003c main
80002008 g     F .text	00000038 _get_interrupt_handler
ffffffff g       *ABS*	00000000 __max_heap_size__
000000a8 g       *ABS*	00000000 __heap_start__
00001000 g       *ABS*	00000000 __stack_size__
8000233c g     O .exception	00000000 ipr_val
00000008 g       .dalign	00000000 _data
8000207c g     F .text	0000004a Delay
00008000 g       .stack	00000000 _estack
00000008 g       .bss	00000000 _edata
000000a8 g       *ABS*	00000000 _end
80002490 g       .dalign	00000000 _data_lma
800020c8 g     F .text	00000000 _stext
00007000 g       .stack	00000000 _stack

So, my own code is safely at or beyond 0x80002000. When I try to program with dfu-programmer, I still get the message

Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore

sma, you said:

Quote:

either you code is linked at 0x800000000 with a trampoline (size 2000h) that will _not_ be programmed {and you'll have the warning message}, or link your code at 0x800002000 without trampoline

so I guess this is expected? But why do you say the trampoline will not be programmed? How does dfu-programmer know not to program it? Judging from the warning, it seems like it *would* write something there. Could someone please explain this more precisely, before I blow away the bootloader and brick my dev board? (I don't have JTAG.)

Alternatively, if someone has a working project that shows how to link directly at 0x80002000, that would be swell. I'm kinda stunned not to have found one yet. I guess the user community is still small?

Thanks,

Mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can someone correct me if I'm wrong, or confirm if I'm correct:

The bootloader cannot overwrite itself. The trampoline is a "dummy" piece of code that takes up the space that the bootloader would otherwise use.

If you do a chip erase via JTAG and program the flash, the trampoline overwrites the bootloader.

If you just program via the bootloader, you will get that error message. You are being warned that there is code (the trampoline) that takes up the same space as the bootloader. However, the bootloader cannot overwrite itself because that part of flash is protected (and can only be erase by a chip erase via JTAG). So if you just ignore that error message and let the bootloader do its thing, the trampoline won't get programmed, and your bootloader should still be there.

Now the bit I haven't figured out yet (because I haven't had a need to figure it out) is getting the fuse bits right. The few times I've used the bootloader as described above, the processor seems to get stuck in the bootloader and my application won't run on powerup/reset. I have been lucky enough to have a JTAG on hand, so haven't bothered to figure that bit out just yet.

Hopefully that may have explained a few things.

Cheers,
Chris.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chrismy wrote:
Can someone correct me if I'm wrong, or confirm if I'm correct:
The bootloader cannot overwrite itself.

That makes total sense, but I've seen at least one anecdote suggesting otherwise:

https://www.avrfreaks.net/index.p...

This is a pretty basic question, and I'm sure there are people here who know the answer. Help, please :?

On a related note, I found a partial answer to my own question about dfu-programmer. When I try to program my test app, it says

Quote:
Bootloader and code overlap. Use --suppress-bootloader-mem to ignore.

which to me means that if I use that option, it will suppress the warning and go ahead and try to overwrite the bootloader! In fact, the man page shows that this is just an unfortunate wording--the actual meaning is precisely the opposite:
Quote:
--suppress-bootloader-mem ignores any data written to the bootloader memory space when flashing the device. This option is particularly useful for the AVR32 chips trampoline code.

But that still doesn't explain whether it is possible to destroy the bootloader via DFU. If it is possible, the trampoline code seems not to help one bit, because it replaces the reset vector with an unconditional jump to 0x80002000, effectively neutering the bootloader. If it is not possible, then why use a trampoline in the first place? Why not just link the main code at 0x80002000 and let the pre-existing bootloader code jump to it?

Clearly I'm missing something here, but what?

Mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, it is physically not possible to erase the bootloader (it's fuse protected with theBOOTPROT, and only a jtag chiperase can do erase the flash)

-sma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correct - it is not possible to overwrite the bootloader on the devices when using DFU (unless of course you use JTAG to erase the DFU section and put your own code there).

If you brick one of the boards, let me know and I'll fix it up for free :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

We have a project based on the AT32UC3A3256 and we have been able to program the uC via the factory installed DFU (as well as via JTAG).

We have used batchisp (under Windows XP) as well as dfu-programmer (under Linux) successfully.

However, to use batchisp, you need to use certain parameters and command sequencing.

See instructions below (from Mike Collins).

After more than 6 months of testing, we have not found a way to trash the dfu bootloader (except using chip erase with JTAG) :-) Your mileage might vary so don't blame us if you brick your chip! However, you can always recover with JTAG :-)

The reason the trampoline code works the way it does is that one can use the same firmware image for programming either via dfu or direct with JTAG. Remember that with JTAG flashing, you can overwrite the whole chip, including the bootloader area. So there will be NO bootloader code there after a JTAG programming. The trampoline allows a jump to the user code.

Alex

Here are the instructions:

Programming via DFU (i.e. USB):

1) the AVR32 Studio implementation doesn't seem to work. Flip doesn't
work for the device either. Must use the batchisp program (in the
Program Files\Atmel\Flip 3.3.4\bin directory). The command line at
works great is:

batchisp -device at32uc3a3256 -hardware usb -operation erase f memory
flash blankcheck loadbuffer programname.elf program verify start reset
0

put the desired file (i.e. programname.elf) in the batchisp directory.

2) You can just leave the trampoline in place for code development.
That allows the user to download using JTAG or using the DFU with the
same *.elf file. With the batchisp DFU the trampoline code is ignored
since it overlaps the DFU protected space.

Reloading DFU using JTAGICE MKII:

1) the AVR32 Studio implementation for programming bootloader doesn't
work. It loads a incorrect FUSE setup that doesn't allow the DFU to
run. To reload DFU: set the Fuse Bits(fff7ffff), set the User
Configuration at 808001fc (4 bytes of 929e2a9e), then just program
the 8K of DFU code

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the very late entry - just saw this post. I wrote dfu-programmer. It isn't possible because the bootloader on the chip will not allow the memory to be overwritten. Using the trampoline code & DFU allows you to program the device via DFU or JTAG without any code changes. If you are only going to use DFU, then you can alter the link map to exist from 0x80002000 as you suggest.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a note if anyone else is still struggling with the "invalid register list" compiler bug which seems to affect many Debian users: The beta release of AVR Studio 2.6 now includes the toolchain as a set of statically linked binaries. Just download and extract the enormous (370MB) zip file, search for the toolchain bin directory, and add it to your path (and get rid of any other avr32 toolchain binaries on your system). This worked for me on 64-bit debian squeeze.

http://www.atmel.no/beta_ware/

At the moment only a 64-bit version is available. The good news is the Atmel people are still working to get all of this accepted upstream, after which most of our difficulties should go away.

People just arriving on this thread may also find the following helpful:

http://blog.stackfoundry.com/201...

I spent a lot of time last spring trying to reverse-engineer something like this. It's a plain old avr32 makefile project that works with DFU and doesn't pull in any of the software framework crud.