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...).