Confirming AVR-GCC supports for AVR Sx Series

[Aloysius Indrayanto]

Hello,
Just some follow up information.

> > So my question is, what is the AVR-GCC equivalent for "mdevice=avr32sd28"
> > and "-msafety-device-features"?
>
> I'll check whether Microchip responds to this.
>
They answer:

-----

"Yes, -msafety-device-features currently does only NOP padding, but
may do more in the future (like say stack pointer overflow/underflow
detection)."

"The NOPs are there to ensure illegal opcode detection/ECC checking
(Section 10.4.11 and Section 16.3.4.2 in
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR32SD20-28-32-Data-Sheet-DS40002629.pdf)
does not trigger when the next flash address following one containing
a valid instruction is in erased/unprogrammed state (or does not
contain a valid instruction). The toolchain (the linker specifically)
will detect such cases and place a NOP there. The typical case is at
the end of code, but there are other cases too (function placed at a
non-contiguous address, for e.g.)."

-----

I think AVR-GCC has something like "-fstack-protector" et al., which
could potentially replace XC8's "-msafety-device-features" if
Microchip ever decides to implement stack pointer overflow/underflow
detection in the future.

As for the Sx series, I suppose it doesn't like 0xFF as an empty flash
value. In my case, NOPs shouldn't be needed, because I could configure
my uploader to fill 0x00 instead of 0xFF when merging sections that
aren't contiguous, and when padding the end of the program to align
with the flash block size.

I know AVR doesn't require the code to be 4-byte aligned, but what
does AVR-GCC (not the linker) do now when the code isn't 4-byte
aligned for AVR Sx series? Is the padding 0x00 (i.e., NOPs), or 0xFF
(empty flash, no code)?

Thank you and best regards,
Aloysius