- Directly read/write DU's flash, EEPROM and user row from PC using USB
- 1.5 KiB (3 pages) flash footprint, with read-only data stored in boot row
avrdude -c <programmer> -p avr<flash>du<n_pin> -Ubootsize:w:0x03:m -Ubootrow:w:build/program.btr -Uflash:w:build/program.hex
A UPDI programmer is required to flash the bootloader itself. Following memories have to be programmed:
FUSE.BOOTSIZE(bootloader size in 512-byte blocks of flash)- Boot Row (used to store constants including descriptors)
- Flash (bootloader)
- As the bootloader occupies the first three pages of flash, the application must have its start offset by
0x600bytes. This can be achieved by adding-Wl,--section-start=.text=0x600to the linker options. By default, the interrupt vector table is placed at the start of the application region, so offsetting the whole.textsection works as long asFUSE.BOOTSIZEis properly configured. - The images has to be in binary format. This can be done with
avr-objcopy -I ihex -O binary <input_hex> <output_binary>.
- Bootloader can be entered by pulling
PC3low on reset. The pin is internally pulled up during sampling, and while the bootloader is running. - DFU interface has three alternate settings each corresponding to flash (0), EEPROM (1) and user row (2). The target partition can be specified using
-a <alt_num>option if you are usingdfu-util. - All of these partitions support both writing/downloading
-Dand reading/uploading-U. - First 1.5 KiB of flash, occupied by bootloader, does not appear in either downloaded or uploaded image. The binary file starts at
0x600. For the other two memories, the image starts at0x0and the entire region is accessible. - Full command would look like
dfu-util -a 0 -D firmware.binfor downloading firmware, ordfu-util -a 1 -U eeprom.binfor uploading EEPROM content.
- Various checks are skipped assuming the host will behave politely. Hardly compliant to USB/DFU specs. Don't use for anything remotely serious.
- That said, the bootloader was tested on AVR32DU32 and AVR16DU20 with
dfu-utiland seemed to be okay. Should work on 64 KiB parts too, though untested since I don't have one. As it involves dynamicFLMAPreconfiguration, it has more chance of something going wrong.