Bootloader size exceeds 2 kb (avr-gcc 4.8.2)

[enkore]

With default options a build for atmega328p (20 MHz) results in a binary size of 2108 bytes (exceeding 2048 bytes by 60 bytes).

Compiling with additional flags -flto -fwhole-program yields 2082 bytes (34 bytes too much, still).

Setting DANGEROUS=1 didn't change anything about the size.

Theoretically the 328p allows up to 4K for the bootloader, but my firmware is already 29K in size and some features are still missing...

By the way, the last usbasploader release by OBdev (2012-12-08) compiles to 1964 bytes with the same settings (328p, 20 MHz).

Compiler used is a recent avr-gcc 4.8.2 on x64.

[baerwolf]

Hi enkore. Thank you for your report. I assume it is toolchain related:

Please try one of these versions: 3.4.2 or 3.4.3 (for example available at http://matrixstorm.com/avr/tinyusbboard/#asmorc) or at directly at Atmel. Even using a recent gcc can still be based on old Atmel patches.

If you bootstrapped your own AVR toolchain: I know some optimizations are missing in the gcc (and binutils) mainline. In this case only switching features off (can_exit, serial flash access ...etc...) will spare flash.

Hope to read from you soon,

BR Stephan

A Warning at the end: Changing the default BLS size (4 --> 2KiB) will cause spminterface to fail! Please manually adapt its addresses or deactivate (NOT recommended) the feature.

[enkore]

If I don't need to write the flash from the booted application, then I don't need spminterface, do I?

However, I also will never write to the EEPROM (at least not from the bootloader), disabling EEPROM_PAGED_ACCESS and EEPROM_BYTE_ACCESS (which will probably disable all EEPROM programming access, I guess) I end up with a 1994 byte binary. Fair enough :)

[baerwolf]

Hi

If I don't need to write the flash from the booted application, then I don't need spminterface, do I?

Yes, but update will never work, too. I really do not recommend it - If you want to change the bootloader in the future (bug, new feature ...etc...) you won't be able to use the existing bootloader to update, and you will need to use external ISP. If you distribute your board to other people, this might be not a good solution.

[enkore]

Ah, thanks for the clarification here. It's just a personal project where I don't have enough space for a ISP connector so my plan is to flash the bootloader onto the MCU using clip connectors and doing regular dev work using the bootloader. Updating the bootloader would then mean to open the case and apply clip connectors again ; I'm ok with that.

One could also see this bootloader-self-updating-inability w/o spminterface as an advantage - you can't brick the device without a programmer and in that case you can easily unbrick it again :)

[baerwolf]

Hi

One could also see this bootloader-self-updating-inability w/o spminterface as an advantage - you can't brick the device without a programmer

This is why there is a feature called magic value. The 32Bit value is intended to block unintentional calls to the do_spm. It helps to distinguish different layout versions of a bootloader and blocks wrong updates from getting installed ;-) An external ISP would help additionally, esp. when testing the updates for delivery (and everything goes wrong the first time ;-) )

How ever, you are right. The main use for the updater have developers remotely deploying updates to their users. (And they don't want to open boxes or interconnect cables ;-) )

So have fun using USBaspLoader, best regards Stephan