8-16 bit: Map file error

[NZ_Design]

What does 0'Error in the address coloum of my map file mean.

Message Edited by CrasyCat on 2007-04-13 11:29 AM

[NZ_Design]

No I had a sucess fully linked case and added a truck load of code and all the routines and declirations that dont fit in in address space 0xc000 have this error. Even all my ram declirations have it.  here is a copy of the datapage set up (.prm file)  and the map file.

and the decliration files.

[CompilerGuru]

So it is a map file of a failed linker invocation (the map file starts with "LINKING FAILED").
Once the linker fails to link a single object, it stops immediately and gives up.
So as the non banked ROM_C000 area is first filled in the prm file, all the other
objects don't get allocated at all and end up with a unallocated address (displayed as 0'Error), hence the many non allocated objects in your map file.

I noted that you are not using the non paged area ROM_4000 at all, so I would recommend to place some of the objects into this area before using ppaged memory.
Something like:
NON_BANKED INTO ROM_C000;
STARTUP,
ROM_VAR,
STRINGS INTO ROM_C000, ROM_4000;
COPY INTO ROM_4000;

There is a theoretically possibility of a linking failure with a fixup overflow if you
place NON_BANKED into more than one segment ("NON_BANKED INTO ROM_C000, ROM_4000" if you are not compiling with -OnB=b switch. So I did explicitly assign NON_BANKED to one of the segments.
(Even if you just use (ROM_C000, ROM_4000) it will either work or fail at link time, not at runtime, also I would not expect this failure to be in the banked memory model.)

Using PPAGE'ed data is also possible, but I would only start to use it if I did run out of the other non banked flash, the code accessing ppaged memory is considerably larger and slower.

Daniel

[CrasyCat · Accepted solution]

Hello

Apparently you have a bunch of constant table in the application and these are taking too much room from the C000-FEFF memory area.

I would recommend you to define (declare these constant tables in a user defined constant section defined with attribute PPAGE.

Example:

#pragma CONST_SEG __PPAGE_SEG MybankedConst

int Fruit[636] = {....};

/* Other banked constants */

#pragma CONST_SEG DEFAULT

Declaration should look as follows:

#pragma CONST_SEG __PPAGE_SEG MybankedConst

extern int Fruit[636];

/* Other banked constants */

#pragma CONST_SEG DEFAULT

Then to place the section in banked memory.

In the .prm file change

    DEFAULT_ROM                  INTO PAGE_30,PAGE_31,PAGE_32,PAGE_33,PAGE_34,PAGE_35,PAGE_36,PAGE_37,
                                      PAGE_38,PAGE_39,PAGE_3A,PAGE_3B,PAGE_3C,PAGE_3D;
into

    DEFAULT_ROM, MybankedConst                  INTO PAGE_30,PAGE_31,PAGE_32,PAGE_33,PAGE_34,PAGE_35,PAGE_36,PAGE_37,
                                      PAGE_38,PAGE_39,PAGE_3A,PAGE_3B,PAGE_3C,PAGE_3D;

Make sure to build your application with option -CpPPAGE=RUNTIME.

If the banked constants are used as parameter in library functions, you may have to re-generate the library telling the compiler you are using banked constants.

I hope this helps. 

CrasyCat

[CompilerGuru]

it means the address is not set/known.
This syntax is quite common for map files which were created in error cases, for example in out of target memory situations. Then all objects which did not get their memory location have this "address".
Do you have this in a successfully linked application? If so, please provide a reproducible case.

Daniel