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
