Bootloader size questions

[welchsteven]

I am trying to use dfu-programmer to load a new version of the LUFA DFU Bootloader onto an atmega16u2 and I am having some trouble with the size of the DFU bootloader. The compiler says it is fine:

AVR Memory Usage
----------------
Device: atmega16u2

Program:    3778 bytes (23.1% Full)
(.text + .data + .bootloader)

Data:        133 bytes (26.0% Full)
(.data + .bss + .noinit)

 [INFO]    : Finished building project "BootloaderDFU".

However, when I go to program it with dfu-programmer I get the following error:

$ dfu-programmer atmega16u2 flash BootloaderDFU.hex --debug 1000 --suppress-bootloader-mem
     target: atmega16u2
    chip_id: 0x2fef
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 1000
device_type: AVR
------ command specific below ------
   validate: true
   hex file: BootloaderDFU.hex

dfu.c:414: dfu_device_init( 1003, 12271, 0x7ffeee301800, true, false )
dfu.c:431: found device at USB:6,0
dfu.c:663: Found DFU Inteface: 0
dfu.c:293: dfu_abort( 0x7ffeee301800 )
dfu.c:204: dfu_get_status( 0x7ffeee301800, 0x7ffeee3016e8 )
dfu.c:230: ==============================
dfu.c:232: status->bStatus: OK (0x00)
dfu.c:233: status->bwPollTimeout: 0x0000 ms
dfu.c:235: status->bState: dfuIDLE (0x02)
dfu.c:236: status->iString: 0x00
dfu.c:237: ------------------------------
dfu.c:688: State: dfuIDLE (2)
atmel.c:1295: atmel_flash( 0x7ffeee301800, 0x7ffeee3016f0, false, false )
atmel.c:1158: atmel_flash_prep_buffer( 0x7ffeee3016f0 )
atmel.c:1335: Flash available from 0x0 to 0x2FFF (64kB p. 0 to 0), 0x3000 bytes.
atmel.c:1339: Data start @ 0xFFFFFFFF: 64kB p 65535; 128B p 0x1FFFFFF + 0x7F offset.
atmel.c:1343: Data end @ 0x3FFF: 64kB p 0; 128B p 0x7F + 0x7F offset.
atmel.c:1348: Totals: 0x4001 bytes, 4261412993 128B pages, 4294901762 64kB byte pages.
atmel.c:1353: ERROR: Data exists outside of the valid target flash region.
Hex file error, use debug for more info.
commands.c:360: Error writing memory data. (err -1)

To me it looks like the total size is way off. All the address ranges in the hex file are 0x3XXX so that should be the right location for a 4K bootloader size. I thought maybe there was something wrong with dfu-programmer, so I tried avrdude as well and I can program the bootloader with no problem and the bootloader works with no issues, but the reported size is again quite large.

$ avrdude -p m16u2 -c jtag3isp -U flash:w:BootloaderDFU.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9489 (probably m16u2)
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: writing flash (16056 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 16056 bytes of flash written
avrdude: verifying flash memory against BootloaderDFU.hex:
avrdude: load data flash data from input file BootloaderDFU.hex:
avrdude: input file BootloaderDFU.hex auto detected as Intel Hex
avrdude: input file BootloaderDFU.hex contains **16056** bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: **16056** bytes of flash verified

avrdude: safemode: Fuses OK (E:F4, H:D9, L:5E)

avrdude done.  Thank you.

Am I crazy here or is there something wrong with the hex file I am generating?

[abcminiuser]

That sounds like the tools are interpreting the HEX file as having padding from the starting address of the flash, to the start of the bootloader region. That's normal in the case of avrdude.

For the first case, you're trying to program the bootloader region via the existing DFU bootloader, which won't work. You need to program in the bootloader using an external programmer first, as the bootloader can't overwrite itself in-situ. Flashing with avrdude over ISP/JTAG/etc. and then using the loaded bootloader to program the application region with an app via the dfu-programmer tool should work.

[welchsteven]

Thanks for getting back to me and I am sorry for the long delay. I suppose it is good to know that what I was trying to do was impossible and that this is expected behavior! I have had no issues actually programming the bootloader with an external programmer, except that the size is wrong. I will dig through the appropriate code to see if any improvements in padding assumption can be made there.