XMega/Mega0/Tiny0/Tiny1 avr-libc boot.h (spm wrappers) support

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just checking:

 

there's still no avr-libc support equivalent to boot.h for the xmega chips, right?

And the new "xtiny" and "mega 0" chips have similar boot/spm usage?

 

Is there a different set of standard wrapper functions for SPM on these chips, or is everyone rolling their own?  :-(

(I did find various freaks discussions with sample xmega bootloader code, dating back to 2009...  That's 10 years ago!)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My Xmega bootloader uses routines I lifted out of the ASF/NVM driver code. If you don't have a copy install with Studio, you can find the files on Github.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(ah.  Mega0 and XTiny at least do not use SPM for writing flash, and in fact have removed SPM from the instruction set summary.)

(They use the NVM Controller peripheral instead.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh.  The flash write function for Mega0/etc is pretty neat.

 

I'm a bit annoyed that I don't think you can duplicate the "a program can write to anywhere in flash" of the "self-programming" older ATtiny chips.

It means that you really do need to generate different binaries for a chip if you're using a bootloader, vs direct programming (since the bootloader has to be at zero.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
It means that you really do need to generate different binaries for a chip if you're using a bootloader, vs direct programming (since the bootloader has to be at zero.)

 

This is done using -Wl,--section-start=.text=ADDRESS, where ADDRESS points to immediately after the bootloader, right?

 

edit: or -Wl,-Ttext=ADDRESS

Last Edited: Sun. Sep 1, 2019 - 11:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is done using -Wl,--section-start=.text=ADDRESS, where ADDRESS points to immediately after the bootloader, right?

Yes.  But a bootloader is supposed to be transparent (IMO) - I shouldn't have separate compile rules for "xxx board with bootloader" and "xxx board with programmer."
I suppose you move the application even if no bootloader is present - the AVR will happily execute those 0xFFFF instructions (with little effect) until it gets to the start vector at the post-bootloader address.

I guess I should have noticed that this was happening on many ARM platforms :-(

 

This is different than the Xmegas, BTW.  They still have the boot section at the end of flash.