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

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

[xiangjun_rong]

Hi, J

The SDK of DSC is very old, the SDK was replaced by Processor Expert in about 2003 year, we can not get an engineer who is familiar with SDK and corresponding LCF now.

Currently, the document "Targeting 56800" is the only doc which you can refer to.

Sorry for not helping you

BR

Xiangjun Rong

[j___]

Also, why are _Mirror sections used at all?

The memory allocations are identical.

What is gained by duplicating the entry with _Mirror and then switching back-and-forth when defining the sections?

[j___]

Additionally, I have the following memory defined in the LCF:

.pFlash  (RX) : ORIGIN = 0X0100, LENGTH = 0xEEFA

When I check the size using SIZEOF(.pFlash), it is 0xF838.

How can this be?

The size is the length so it should be 0xEEFA. Even if it started from 0x0000, which it shouldn't, the size would be 0xEFFA.

Is the SIZEOF feature broken in the compiler\linker?

[j___]

In the example:

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

Why is one considered (RW) while the other is (RWX)?

This doesn't make any sense. There is no unified memory on this part. The section is named with .x. So therefore, I would expect both sections to be data RAM. Further, the interrupt vectors will placed at 0x00 - 0x80 in flash, so this .xIntRAM_Mirror sections starting at 0x40 MUST be data memory.

So, again, why the (RWX) designation?

These questions really need to go to someone in the compiler group.

[j___]

I cannot find any information describing the operator precedence (order of operation) concerning addition & division in the LCF.

This LCF line uses both addition & division.

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

Which document has the precedence information for the LCF?

At least I was able to find the description for SIZEOF in the document "Targeting 56800", page DSP-129.