Bug: EEPROM addresses after compiling changed in new Arduino Software 1.6.4

[jack-zande]

Hello all,

I use EEMEM with library #include <avr/eeprom.h>.
It very practical, because I can use "read block", "update block" and "write block"
without giving EEPROM addresses.

Example:

EEMEM uint8_t EEPROM_K[12] =
{ 0xE8, 0x03, 0x00, 0x00,
  0xD0, 0x07, 0x00, 0x00,
  0xC8, 0x00, 0x00, 0x00 };           // E8 03 00 00 _ D0 07 00 00 _ C8 00 00 00

uint8_t K_bytes[12];

eeprom_read_block((void*)K_bytes, (const void*)EEPROM_K, 12);

When doing variable declaration, according to the AVR-documentation (attached),
the compiler should begin with address 0 and ascending 1,2,3, ................

In the new version 1.6.4 the last EEMEM declaration begins with address 0. It has
changed the EEPROM addressing in a reversed way (from down to up)

V1.0.5

                                                       // EEPROM-addresses
EEMEM char string1[6]= "abcdef";  // 0, 1, 2 , 3, 4, 5

EEMEM char string2[6]= "ghijkl";    // 6, 7, 8, 9, 10, 11

Now with V1.6.4 (not logical for humans)

                                                        // EEPROM-addresses
EEMEM char string1[6]= "abcdef";  // 6, 7, 8, 9, 10, 11

EEMEM char string2[6]= "ghijkl";    // 0, 1, 2 , 3, 4, 5

Jack

[jack-zande]

Hi,

Library used #include <avr/eeprom.h>
EEP-files examples

Declarations are:
EEMEM char EEPROM_STRING[6] =
{'R','B','0','_','V','1'}; // "RB0_V1"

EEMEM uint8_t EEPROM_K[12] =
{ 0xE8, 0x03, 0x00, 0x00,
0xD0, 0x07, 0x00, 0x00,
0xC8, 0x00, 0x00, 0x00 }; // E8 03 00 00 _ D0 07 00 00 _ C8 00 00 00

EEMEM uint8_t EEPROM_P[10] =
{ 0xC8, 0x00,
0x0E, 0x00,
0x03, 0x00,
0x01, 0x00,
0x06, 0x00 }; // C8 00 _ 0E 00 _ 03 00 _ 01 00 _ 06 00

EEMEM uint8_t EEPROM_M[2] =
{ 0x64, 0x64 }; // 64 _ 64

[cmaglie]

The EEMEM attribute ensure that your data will go into EEPROM section but it doesn't guarantees the ordering: the compiler is free to sort the data in any arbitrary order.

The documentation here says:

EEMEM Attribute expression causing a variable to be allocated within the .eeprom section.

And indeed in all your examples the variable are in the .eeprom section.

Maybe you want to access the data using the symbols EEPROM_STRING, EEPROM_K and EEPROM_P, etc., instead of the absolute address.

[jack-zande]

Hi Maglie,

I use absolute addressing as well. All my programs worked well with V1.0.5.
But in the newer Version 1.6.4 I need to adjust my programs again. So un apdate
makes my life not easier again. Well so be it again. I don't understand the change
in compiling it in a different way.

Upgrades are made for guinea pigs and not for serious people, like me ;-) .
Is there any way to get rid off the popup window " There is a new version to upgrade your ARDUINO VERSION"?

Jack

[matthijskooijman]

I recall another (unrelated) bug report (for some other project), where a bug was exposed because a newer compiler version ordered symbols reversed compared to an older compiler version. There, the suggested fix was to add -fno-toplevel-reorder to the compiler commandline.

Perhaps that works here as well? You can try by modifying your platform.txt file. Not sure if there are any (performance) downsides connected to that option, though.

[jack-zande]

Hello Mathijs,

Thanks for your info. Life is beautiful, when others will help you.

I have looked in this file what is there.
I am not familiar with the syntaxes in this platform.txt-file. So what can I change there?

Jack

[matthijskooijman]

This file lists various compiler options. In particular, there are lines starting with:

compiler.cpp.flags=
compiler.c.flags=
compiler.c.elf.flags=

To each of these lines add " -fno-toplevel-reorder" (without quotes, but include the space to separate this new option from the previous ones). Then restart the IDE to reload the file and try again.

If this breaks the compilation entirely, remove the option from the last of the three lines above again (there's a chance that this option is only supported during compilation, not linking). Also, make sure you use the "avr/platform.txt", not "sam/platform.txt" (if you even have the latter).

[cmaglie]

I'm closing this one since it's gcc related, we can't do much to solve it (besides downgrading the compiler version...).

[matthijskooijman]

@cmaglie, I actually think that adding -fno-toplevel-reorder could fix this (though it also prevents reordering functions and data I think so it could pessimize performance a bit). But given the original poster hasn't responded with a result of his testing, I guess closing this is fine for now.

Also, a (slightly) more portable solution for an EEPROM layout would be to have just a single global variable in EEPROM, using a struct to let it contain multiple subfields.

[xcvista]

I think this "update compiler and lose compatibility" reveals a bit of code smell: your code depend on implementation details of a compiler.

I would suggest in the next version put all of your EEMEM variables into one big struct. C language specification requires members of struct be kept in order just like EEMEM however unlike struct which exist only in one single file, EEMEM can spread across multiple files. The catch here is that the order of linking is undetermined and implementation-specific. So moving EEMEM variables into a single struct gives you double assurance on how the members are laid out - there is only one file containing the .eeprom section so the linker have nothing to mangle with, and the language itself is used to guarantee the order or members instead of a compiler feature.

[Chris--A]

Yep, that is exactly what EEMEM is for, just like PROGMEM. The ability to initialize is just a bonus (but necessary for flash data).