Using the DFU bootloader on ATmega8U2

821 views
Skip to first unread message

László Monda

unread,
Mar 3, 2011, 9:56:11 PM3/3/11
to LUFA Library Support List
Hey Dean,

First, I've changed Bootloaders/DFU/makefile:

MCU = atmega8u2
BOARD = NONE
F_CPU = 16000000

Then executed make:

Compiling C: BootloaderDFU.c
avr-gcc -c -mmcu=atmega8u2 -I. -gdwarf-2 -DF_CPU=16000000UL -
DF_CLOCK=16000000UL -DBOARD=BOARD_NONE -DBOOT_START_ADDR=0x1E000UL -D
USB_DEVICE_ONLY -D DEVICE_STATE_AS_GPIOR=0 -D CONTROL_ONLY_DEVICE -D
FIXED_CONTROL_ENDPOINT_SIZE=32 -D FIXED_NUM_CONFIGURATIONS=1 -D
USE_RAM_DESCRIPTORS -D USE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED |
USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -D NO_INTERNAL_SERIAL -D
NO_DEVICE_SELF_POWER -D NO_DEVICE_REMOTE_WAKEUP -D NO_STREAM_CALLBACKS
-D NO_SOF_EVENTS -Os -funsigned-char -funsigned-bitfields -ffunction-
sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-
strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=./
BootloaderDFU.lst -I../../ -std=c99 -MMD -MP -MF .dep/
BootloaderDFU.o.d BootloaderDFU.c -o BootloaderDFU.o
BootloaderDFU.c: In function 'SetupHardware':
BootloaderDFU.c:127: warning: implicit declaration of function
'clock_prescale_set'
BootloaderDFU.c:127: error: 'clock_div_1' undeclared (first use in
this function)
BootloaderDFU.c:127: error: (Each undeclared identifier is reported
only once
BootloaderDFU.c:127: error: for each function it appears in.)
make: *** [BootloaderDFU.o] Error 1

After removing the clock_prescale_set(clock_div_1) call (I'm not sure
whether it's a good idea) I re-executed make. The build seemed to be
perfect until I realized that I couldn't upload the firmware to the
MCU for some reason:

laci@nitehawk:~/projects/lufa/Bootloaders/DFU$ p /usr/bin/avrdude -c
usbtiny -p usb162 -F -U flash:w:BootloaderDFU.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.01s
avrdude: Device signature = 0x1e9389
avrdude: Expected signature for AT90USB162 is 1E 94 82
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be
performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "BootloaderDFU.hex"
avrdude: input file BootloaderDFU.hex auto detected as Intel Hex
avrdude: ERROR: address 0x1e010 out of range at line 2 of
BootloaderDFU.hex
avrdude: write to file 'BootloaderDFU.hex' failed
avrdude: safemode: Fuses OK
avrdude done. Thank you.

Thanks in advance for your help!

Laci

Mitch Davis

unread,
Mar 3, 2011, 10:34:32 PM3/3/11
to lufa-s...@googlegroups.com, László Monda
On Fri, Mar 4, 2011 at 1:56 PM, László Monda <mond...@gmail.com> wrote:
> Hey Dean,

>
> I couldn't upload the firmware to the MCU for some reason:
>
> laci@nitehawk:~/projects/lufa/Bootloaders/DFU$ p /usr/bin/avrdude -c
> usbtiny -p usb162 -F -U flash:w:BootloaderDFU.hex
> avrdude: AVR device initialized and ready to accept instructions
> Reading | ################################################## | 100%
> 0.01s
> avrdude: Device signature = 0x1e9389
> avrdude: Expected signature for AT90USB162 is 1E 94 82
> avrdude: NOTE: FLASH memory has been specified, an erase cycle will be
> performed
>         To disable this feature, specify the -D option.
> avrdude: erasing chip
> avrdude: reading input file "BootloaderDFU.hex"
> avrdude: input file BootloaderDFU.hex auto detected as Intel Hex
> avrdude: ERROR: address 0x1e010 out of range at line 2 of
> BootloaderDFU.hex

I could be horribly wrong, but this could well be because avrdude
thinks you're talking to an AT90USB162, which has less memory than the
ATmega8U2, and your firmware file has addresses which are valid for an
ATmega8U2 but invalid for an AT90USB162.

In order to teach avrdude about the ATmega8U2, you might find this post helpful:

http://forums.adafruit.com/viewtopic.php?f=24&t=19357

Mitch.

Opendous

unread,
Mar 4, 2011, 1:25:33 AM3/4/11
to LUFA Library Support List
>clock_prescale_set(clock_div_1)

You need an updated version of avr-libc. Either update it or
Include the following header in your Descriptors.h:
http://code.google.com/p/micropendous/source/browse/trunk/Micropendous/libs/LUFA/LUFA/MissingDefines.h

>-DBOOT_START_ADDR=0x1E000UL

That is wrong. That is the start address for an AT90USB1287. Look
at Pg.239 Table 23-8 of the ATmega8U2 datasheet. The 8U2 bootloader
is 2048 words long which is 4096 bytes and the start address is word
0x800 but the start byte address would then be 0x1000. Set BOOT_START
= 0x1000 in the makefile.

László Monda

unread,
Mar 4, 2011, 8:21:31 PM3/4/11
to Mitch Davis, lufa-support

You're right about the memory difference between the two MCUs. I
should have used the AT90USB82 as a compatible MCU, but using either
of them makes no difference, I get the same error. Using the ATmega8U2
is a little bit more elegant however because the -F flag is not
needed.

--
László Monda <http://monda.hu>

László Monda

unread,
Mar 4, 2011, 8:40:43 PM3/4/11
to lufa-support, Opendous
You're the man! I was able to build the firmware by including
MissingDefines.h and I was able to upload it to the MCU by changing
DBOOT_START_ADDR to 0x1000 in the makefile.

Now I get this from dmesg when I plug in the device into USB:

[46137.010245] hub 4-0:1.0: unable to enumerate USB device on port 1
[46226.332554] usb 4-1: new full speed USB device using uhci_hcd and address 114

After keeping HWB pressed, pressing RESET finally releasing HWB and
expecting to get into bootloader mode I get this:

[46241.450066] usb 4-1: device descriptor read/64, error -110
[46256.682545] usb 4-1: device descriptor read/64, error -110
[46256.910095] usb 4-1: new full speed USB device using uhci_hcd and address 115

When executing dfu-programmer or lsusb I can wait ages and nothing
happens. Something is not right.

Also, I'm confused about how much flash the DFU firmware really
occupies. Upon building the firmware I got this:

Size after:
AVR Memory Usage
----------------
Device: atmega8u2

Program: 3334 bytes (40.7% Full)
(.text + .data + .bootloader)

Data: 127 bytes (24.8% Full)
(.data + .bss + .noinit)


But when uploading it to the MCU I get the message:
"avrdude: writing flash (7430 bytes):"

Thanks in advance!

> --
> You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
> To post to this group, send email to lufa-s...@googlegroups.com.
> To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

Opendous

unread,
Mar 5, 2011, 12:08:55 PM3/5/11
to LUFA Library Support List
>But when uploading it to the MCU I get the message:
>"avrdude: writing flash (7430 bytes):"

The bootloader goes at the end of FLASH memory so avr-dude has to
write the full FLASH array 4096+3334 = 7430. The first 4kb are set to
0.

>After keeping HWB pressed, pressing RESET finally ...

Once you have loaded the DFU Bootloader into FLASH it should start
the first time you plug it your board as there is not other firmware.

Did you add USB .rule permissions for the AVR DFU Bootloaders?
http://code.google.com/p/micropendous/wiki/SettingUpUbuntu904Linux

After plugging in your board run sudo lsusb -vvv and see if the
ATmega8U2 VID and PID are in your .rule file.
> >http://code.google.com/p/micropendous/source/browse/trunk/Micropendou...
> > For more options, visit this group athttp://groups.google.com/group/lufa-support?hl=en.

László Monda

unread,
Mar 17, 2011, 12:02:15 PM3/17/11
to lufa-support, Opendous
On Sat, Mar 5, 2011 at 6:08 PM, Opendous <opendous...@gmail.com> wrote:
>>But when uploading it to the MCU I get the message:
>>"avrdude: writing flash (7430 bytes):"
>
>  The bootloader goes at the end of FLASH memory so avr-dude has to
> write the full FLASH array 4096+3334 = 7430.  The first 4kb are set to
> 0.

Thanks, that explains everything.

>>After keeping HWB pressed, pressing RESET finally ...
>
>  Once you have loaded the DFU Bootloader into FLASH it should start
> the first time you plug it your board as there is not other firmware.
>
>  Did you add USB .rule permissions for the AVR DFU Bootloaders?
> http://code.google.com/p/micropendous/wiki/SettingUpUbuntu904Linux
>
>  After plugging in your board run  sudo lsusb -vvv  and see if the
> ATmega8U2 VID and PID are in your .rule file.

My device doesn't get enumerated, I get the same dmesg errors as I've
already mentioned. In the past I've successfully used an AT90USBKEY
and a breadboarded AT90USB1286. Those had the DFU factory-installed.

The strange thing is that I can program this ATmega8U2 through ISP and
I can make it communicate with the host using the CDC demo so my
custom made PCB should be good. Yet, I cannot make the DFU bootloader
work with it. I'm thinking about breadboarding this MCU and trying to
upload DFU that way because DFU doesn't really seem to work with my
PCB for some reason.

> For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

Dean Camera

unread,
Mar 18, 2011, 1:42:41 AM3/18/11
to LUFA Library Support List
Repeat after me: "Premature optimization is the root of all evil".
Also applicable: "If it ain't broke, don't fix it", and "Don't commit
until you test".

I've reverted the bad optimization patch I made a few weeks ago while
still in Norway, where I couldn't test it to see the obvious - my
logic for extracting out the descriptor length algorithmically to save
FLASH space doesn't work on the configuration descriptor, since it was
grabbing the configuration descriptor header's length and not the
length of the entire configuration descriptor.

The latest SVN revision should work once again, and now I'll stop
messing with it when I don't have the hardware around to test out my
changes. Sorry!

- Dean

On Mar 18, 3:02 am, László Monda <mondal...@gmail.com> wrote:

László Monda

unread,
Mar 20, 2011, 6:52:41 PM3/20/11
to lufa-support, Dean Camera
Dean, you're the man! The DFU bootloader of the latest SVN now works
like a charm.

Thanks a lot and keep it up!

> For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

Reply all
Reply to author
Forward
0 new messages