I created a structure about data fields, which are located in a structure in xdata area. The informal structure itself should be in code area.
typedef struct { unsigned char *pucRamAddr; eNvmDevice eDeviceId; // enum type unsigned short tNvmAddr; unsigned short tLength; unsigned char code *pucRomDefaults; char ucFlags; } TNvmBlock; extern const TNvmBlock code tNvmBlock[NVM_BLOCK_COUNT];
Selected model is LARGE. Size of TNvmBlock is usually 11.
So pucRamAddr should point to the element within the xdata structure:
But after linking with BL51 at the pointer entry there is only the Offset within the xdata Structure, the added base address is missing.
I tried to define pucRamAddr as xdata pointer, but then the size of the struct was reduced to 10, although the pucRamAddr were still 2 Byte ???
unsigned char xdata *pucRamAddr;
The pointer target itself were defined like &(tStruct.Element)
Why doesn't the linker fill in the correct xdata address of the Element? And why schrinks the structure size somewhere else when I define the pointer as xdata * ?
Not sure I quite understand your problem.
"So pucRamAddr should point to the element within the xdata structure"
Only when you provide code to make it so - the Linker won't do that for you.
Because pucRamAddr is located in the code section it's only possible to bring the content into it through default initialization through the linker. Therefore in the default initialization is something like
const TNvmBlock CODE tNvmBlock[NVM_BLOCK_COUNT] = { {&(tStruct.Element), ... }, ... }
Usually linkers can fill in the correct address (base of "Struct" + offset of "Element") into the code section, in my at the Output of BL51 there is only the Offset of "Element" within "Struct".
Sorry, I was mistaken: the xdata structure was accidentally located to Address 0. So the address was always correct in code too.
With a 16-bit addressable XDATA range, an xdata pointer is expected to be 2 bytes large. A generic pointer on the other hand, needs an extra byte just to know what memory type it points to so a generic pointer is larger and slower. This is one of the strange workarounds needed when implementing C in a processor that is C-hostile.
Yes - I was including that in, "...provide code to make it so".
You didn't show or mention any initialisation in your initial post.
Anyhow - glad is fixed now!
:-)