AnsweredAssumed Answered

EEE - RAM-Var - How to not initialise with Zeros

Question asked by Sascha Pfengler on Mar 30, 2017
Latest reply on Mar 30, 2017 by Daniel Martynek

If I declare an EEE-variable in this way:

#define U16_ARR_SIZE_BYTE ((uint16)128u)

typedef struct
{
uint16 au16P0[U16_ARR_SIZE_BYTE];
uint16 au16P1[U16_ARR_SIZE_BYTE];
uint16 au16P2[U16_ARR_SIZE_BYTE];
uint16 au16P3[U16_ARR_SIZE_BYTE];
} TS_EEE;

 

#pragma DATA_SEG EEE
static TS_EEE s_tsEee;
#pragma DATA_SEG DEFAULT

 

It is automatically being filled with zeros at the start of the application.

 

If I add the @-Operator to specify the exact location, the last state of s_tsEee is loaded at the start of the application, as it should be.

 

#pragma DATA_SEG EEE
static TS_EEE s_tsEee @0x0C00;
#pragma DATA_SEG DEFAULT

 

EEE is working for me as long as I use @ or only pointers to struct.

I would like to use the first version (without @) since it won't let you compile if consecutive Data / Structures are too large for one EEE-Window.

With the @-solution, the code compiles but will result in excess-data not being applied to EEE-NV.

 

For example...

typedef struct
{
uint16 au16P0[U16_ARR_SIZE_BYTE];
uint16 au16P1[U16_ARR_SIZE_BYTE];
uint16 au16P2[U16_ARR_SIZE_BYTE];
uint16 au16P3[U16_ARR_SIZE_BYTE];

uint16 au16P4[U16_ARR_SIZE_BYTE];
} TS_EEE;

... would compile/link although being 256 byte too big for one window.

 

So in short, is there a way / pragma to prevent 0-Initialization without disabling linker-security checks?

Original Attachment has been moved to: Prm.prm.zip

Outcomes