Fault 1.3: Memory layout on XMEGA not ideal

Hi,

I was able to successfully glitch the XMEGA in this lab. However, my output didn’t show the “decrypted” data. It only showed the input + a ton of 0x00. Then I took a look at the map file and found that the buffers for the input and decrypted data where in opposite order of what you expect:

0x000000000080207c                data_buffer
0x00000000008020a4                ascii_buffer

I also saw that you already seemed to have taken this into account in the bootloader.c source file but then changed your mind and hoped that the compiler would do the “right” thing:

53 //uint8_t buffer[ASCII_BUFLEN + DATA_BUFLEN];
54 //uint8_t* ascii_buffer = buffer;
55 //uint8_t* data_buffer = buffer + ASCII_BUFLEN;
56 uint8_t ascii_buffer[ASCII_BUFLEN];
57 uint8_t data_buffer[DATA_BUFLEN];

un-commenting line 53-55 and commenting out line 56-57 and I can see the “decrypted” output in my glitch data.

My avr-gcc version is as follows:
$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/11.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/11.2.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-11.2.0/configure --disable-install-libiberty --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-linker-build-id --disable-nls --disable-werror --disable-__cxa_atexit --enable-checking=release --enable-clocale=gnu --enable-gnu-unique-object --enable-gold --enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin --enable-shared --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr --with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld --with-plugin-ld=ld.gold --with-system-zlib --with-isl --enable-gnu-indirect-function
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)

Any reason why you don’t want to make the ordering of memory explicit?

Thanks!

My guess is that the compiler changed the memory layout at some point and, since we focus more on the STM32F3 at this point, never caught it.

I don’t think there’s really a reason not to make the ordering explicit, so I’ll make that change for the next release.

Alex

Hi Alex,

Thank you! That will make life easier for the next person that might have faced the same issue!