Closed welchsteven closed 4 years ago
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.
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.
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:
However, when I go to program it with dfu-programmer I get the following error:
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.
Am I crazy here or is there something wrong with the hex file I am generating?