Questions around the A3U and the USB DFU boot loader avr1916

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

I'm preparing for a project with an xmega A3U and would like to be able to use the USB DFU boot loader (avr1916) to install / update the software. I find the documentation a bit lacking.

1) The AVR seems to show up 'unknown device' in windows and need a 'FLIP' driver installed. How does this work out in Linux with avrdude ?

2) Is avrdude even supported/working with the avr1916 DFU boot loader ?
I am unable to find a reference, maybe not enough Google-fu.

3) There is the remark 'when using parts with pre-programmed DFU boot loader' in the avr1916 paper. Can I order XMEGA-A3Us with the avr1916 boot loader pre-programmed ?
I'd like that because then I do not need the initial programming of the bootloader.

Markus

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

Markus

I use http://dfu-programmer.sourceforg...

For my at90usb162 & atmega32u2

I chose to get the source & build it , to get the latest.
But i could have used "apt-get" , and accept that version.

Compiles/Installs cleanly.

Edit: Targets , from arguments.h

enum targets_enum { tar_at89c51snd1c,
                    tar_at89c51snd2c,
                    tar_at89c5130,
                    tar_at89c5131,
                    tar_at89c5132,
                    tar_at90usb1287,
                    tar_at90usb1286,
                    tar_at90usb1287_4k,
                    tar_at90usb1286_4k,
                    tar_at90usb647,
                    tar_at90usb646,
                    tar_at90usb162,
                    tar_at90usb82,
                    tar_atmega32u6,
                    tar_atmega32u4,
                    tar_atmega32u2,
                    tar_atmega16u4,
                    tar_atmega8u2,
                    tar_at32uc3b064,
                    tar_at32uc3b164,
                    tar_at32uc3b0128,
                    tar_at32uc3b1128,
                    tar_at32uc3b0256,
                    tar_at32uc3b1256,
                    tar_at32uc3b0256es,
                    tar_at32uc3b1256es,
                    tar_at32uc3b0512,
                    tar_at32uc3b1512,
                    tar_at32uc3a0128,
                    tar_at32uc3a1128,
                    tar_at32uc3a0256,
                    tar_at32uc3a1256,
                    tar_at32uc3a0512,
                    tar_at32uc3a1512,
                    tar_at32uc3a0512es,
                    tar_at32uc3a1512es,
                    tar_at32uc3a364,
                    tar_at32uc3a364s,
                    tar_at32uc3a3128,
                    tar_at32uc3a3128s,
                    tar_at32uc3a3256,
                    tar_at32uc3a3256s,
                    tar_at32uc3c064,
                    tar_at32uc3c0128,
                    tar_at32uc3c0256,
                    tar_at32uc3c0512,
                    tar_at32uc3c164,
                    tar_at32uc3c1128,
                    tar_at32uc3c1256,
                    tar_at32uc3c1512,
                    tar_at32uc3c264,
                    tar_at32uc3c2128,
                    tar_at32uc3c2256,
                    tar_at32uc3c2512,
                    tar_none };

Edit2: ... Oopzz no Xmega support at all , well you could change that 8)

/Bingo

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

I see the lack of Linux support for now, this may not be a deal-breaker as my dragon is working fine. This is more for others, I intend to publish my design and would like that others don't need a PDI programmer to update the firmware.

I even would like to say 'just order a xmega with the pre-programmed DFU feature' for people to get around the chicken and egg problem of the initial installation.

Markus

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

I asked our "local Guru ... Dean" , about adding xmega support to the dfu-programmer

The answer was :

Quote:
A quick look at the code seems to indicate that it is the same codebase as the UC3 devices, in terms of actual functional logic -- so if it works for the UC3 devices, just adding the device IDs should be enough to make it work.

Dean

I have no usb-based xmegas (Atmeeelll ...)

Could someone with a linux and an usb-based Xmega try it out ?
Seems to be arguments.c & .h that has to be adapted.

Maybe someone from Finchingfield .... Hint..Hint 8)

/Bingo

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

Bingo600 wrote:
I asked our "local Guru ... Dean" , about adding xmega support to the dfu-programmer

The answer was :

Quote:
A quick look at the code seems to indicate that it is the same codebase as the UC3 devices, in terms of actual functional logic -- so if it works for the UC3 devices, just adding the device IDs should be enough to make it work.

Dean


This worked at least somewhat. I haven't had a chance to test it extensively yet.

If anyone wants to try it out, I started a fork on github, since there isn't much going on on the open-source graveyard known as source forge. I had to change some of the booleans to match the data sheet. I can definitely say that dumping the fuses isn't working, but i guess thats not surprising since its somewhat of a combination of a the UC3 protocol, but it's still an 8-bit mega.

Bingo600 wrote:

I have no usb-based xmegas (Atmeeelll ...)

Could someone with a linux and an usb-based Xmega try it out ?
Seems to be arguments.c & .h that has to be adapted.

I picked up an XMega-B1 Xplained Board this week and am playing around with it. I want to make some nice USB-based applications and it would be awesome if they're user upgradable. I'm also heavily leaning to the A3.