AnsweredAssumed Answered

Embedded SDK manual (SDK 101&127), LCF uses _Mirror & SIZEOF, Why???

Question asked by j... on Sep 30, 2018
Latest reply on Oct 1, 2018 by j...

Looking at the SDK manuals 101/D & 127/D, the examples use _Mirror sections of both x & p RAM.

[EDIT: Correct "Flash & RAM" to "x & p RAM"]

 

From the document example:

    .pIntRAM          (RWX) : ORIGIN = 0x7E00, LENGTH = 0x0200
    .pIntRAM_Mirror   (RWX) : ORIGIN = 0x7E00, LENGTH = 0x0200

 

    .xIntRAM          (RW)  : ORIGIN = 0x0040, LENGTH = 0x0660
    .xIntRAM_Mirror   (RWX) : ORIGIN = 0x0040, LENGTH = 0x0660

 

Then the example goes on to perform some strange placement using these along with SIZEOF() /2. I do not understand why this particular placement is done this way. Why can't the flash-based data just dynamically follow the program .text??

 

Here are a couple of excerpts:

.InitializedDataForProgramRAM : AT (ADDR(.pFlash) + 1 + SIZEOF(.pFlash) / 2)

.ApplicationInitialzedData : AT (ADDR(.pFlash) + 1 +
                                     SIZEOF(.pFlash) / 2 + SIZEOF(.pIntRAM_Mirror) / 2 + 1 )

 

The documentation is extremely poor as provides an example with no context or explanation for this placement scenario. It only raises additional questions that go unanswered within the document.

 

I'm pretty sure that will need to be referred to someone in the compiler \ SDK group. However, I am also pretty sure that that won't happen. But, hopefully someone on the forum will understand this quirky example. The legacy code that I am working on is using this implementation as it came with the SDK boiler-plate. I would like to make changes but there is risk if I do not understand why the placement is done this way.

 

See attached command file example from the SDK guide.

Outcomes