Bootloader size exceeds 2 kb (avr-gcc 4.8.2) about usbasploader

[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