Please help: Memory allocation problem dealing with sections

[RbtGal1351]

Hi,

I'm having a memory allocation problem. (I think.)
I was working with the 2005 RC, but this doesn't work when compiled for the 2006 RC either.

    MPLINK 3.90, Linker
    Copyright (c) 2004 Microchip Technology Inc.
    Error - section '.idata_autonomous.o' can not fit the section. Section '.idata_autonomous.o' length=0x00000123
    Errors    : 1
    BUILD FAILED: Mon Mar 13 00:43:55 2006

I have a big script of autonomous stuff, but its 8 bytes per, x 34 long, which is 272 bytes.
I have 2000 bytes to use. (according to microchip: http://www.microchip.com/stellent/id...ame =en010319)

The other big memory usage is 64 bytes of look up table for driving.


my guess is for each .o you can only use 256 k. and its in "sections".
Suggestions? Help please!

Thanks so much!
I'd like to use this code for SVR in less than three days...
~Stephanie

[Matt Krass]

Originally Posted by RbtGal1351

Hi,

I'm having a memory allocation problem. (I think.)
I was working with the 2005 RC, but this doesn't work when compiled for the 2006 RC either.

    MPLINK 3.90, Linker
    Copyright (c) 2004 Microchip Technology Inc.
    Error - section '.idata_autonomous.o' can not fit the section. Section '.idata_autonomous.o' length=0x00000123
    Errors    : 1
    BUILD FAILED: Mon Mar 13 00:43:55 2006

I have a big script of autonomous stuff, but its 8 bytes per, x 34 long, which is 272 bytes.
I have 2000 bytes to use. (according to microchip: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName =en010319)

The other big memory usage is 64 bytes of look up table for driving.


my guess is for each .o you can only use 256 k. and its in "sections".
Suggestions? Help please!

Thanks so much!
I'd like to use this code for SVR in less than three days...
~Stephanie

I don't think you can have any single variable or array over 256 bytes in size, that could be your problem, can you condense the script array at all?

[RbtGal1351]

Well I just got the same error message after shortening the array and adding the same number of single unsigned char variables.

So I think that the 256k (or about) limit is for the file, not a single variable.

On second thought, it could just be both.

[devicenull]

Try this, if the script is set at compile time, and not changed:

Instead of

unsigned char someArray[]....

use

rom const unsigned char someArray[]...

And you shouldn't have that problem anymore.. if that doesn't help, search for "lookup tables"

[Mike Bortfeldt]

Stephanie,

There are a couple of things you can do to fix this problem. As Matt mentioned, you can't have a single array greater than 256 bytes in data memory. In fact, unless to tell the compiler otherwise, you can't have more than 256 bytes of static variables defined in any file. From your error, it looks like you are initializing the variable list. If you do not need to write to these variables (read-only) then you can define them as "rom". This places them in program (flash) memory with your code as shown below. You can access them identically to a data variable except you no longer have the 256 byte limit. (Note that if you use pointers, you need to define the pointer as rom as well)

// Data Memory (this generates the error):
static unsigned char myvariable[8,34];

// Program Memory (this will work):
rom unsigned char myvariable[8,34];

If you need to write to these variables, then you will have to make sure that no variable array is greater than 256 bytes. So you could either shorten the array, or split it into multiple arrays. Then you need to tell the compiler to place them into different sections similar to the following. In this example, the array is split into 2 parts of [4,34].

// file global variable split into 2 sections
#pragma udata vararray1
unsigned char myvariable1[4,34];
#pragma udata vararray2
unsigned char myvariable2[4,34];
#pragma udata

The #pragma statement tells the compiler to split the variables into two sections ("udata" indicate an uninitialized data array, "vararray1" is just a unique name for the section - use "idata" instead of "udata" if you are initializing the array with values). These sections can then be placed into different 256 byte memory banks. The "rom" qualifier is the way to go if you don't need to write to the variables as it is an easy change and should require modification to your program as long as you do not use pointers (otherwise define the pointer as rom as well like: rom unsigned char *varpointer)

Mike

[ericand]

Can't you have data bigger than 256 bytes if you edit the linker script to create some sections that are bigger? You might need
some pragma statements to allocate your data into a specific
memory location.

I think the compiler can generate code to address larger sections of data, it is just that it needs to know that the data structure does this, so it can do the right sort of addressing.

It seems to me that the linker script sets the sections to be 256 bytes since that will work for most people and it produces the quickest code since the data offsets fit into the instructions without the need to manipulate extra registers.

[Mike Bortfeldt]

Good point about the linker script. You can change one of the DATABANK statements to make a larger section. For example, change:

DATABANK NAME=gpr9 START=0x900 END=0x9FF

to:

DATABANK NAME=gpr9 START=0x900 END=0AFF

Then delete the gpr10 DATABANK line. This would give you a 512 byte block for your data. It's not as efficient to use, but it should work (I just wrote a test program and it ran fine). You may have to do a "build all", but the compiler was smart enough in my simple test case to find the correct memory bank without it.

Mike

[RbtGal1351]

Oh my gosh, thank you so much Matt Krass, devicenull, Mike Bortfeldt, and ericand!!
It works now; I've changed the array to a rom const.


Questions, though... (I want to know what this does more specifically, seeing as it is now an integral part of the software.)

1) What is the memory usage limit on each file or variable in rom?

2) According to Microchip's data sheet , there are three types of memory:
• Program Memory
• Data RAM
• Data EEPROM
Which does the "rom const" access? EEPROM?

3) Is there more info about the "rom const" somewhere that I should know about? I can't find it in Microchip's data sheet or anywhere on IFI Robotics.

Thanks so much!!
~Stephanie

[Mike Bortfeldt]

Stephanie,

More information on the "rom" qualifier can be found in the MPLAB C18 C Compiler User's Guide. (In the older version of this document it was in section 2.4.3, but that might have changed in version 3.0 that is available on Microchip's website.) In short, "rom" indicates program memory and as for a size limitation, I would guess it would either be limited to the size of either a signed or an unsigned short (32k or 64k), although I don't have any specific information to back that up.

Mike

[ericand]

The "rom const" directive is in the C18 manual. What it says is that the data that it refers to, (whatever its type - char, int, struct, array...) is not going to change (the const part). Further it says that you want this data to be stored in the program memory (the rom part).

The compiler will look at the directive and allocate the space for the data along with the program in the program memory which is much much bigger than the RAM. The compiler will make sure that the addressing modes in the generated machine code for accessing that data are appropriate for pulling data out of the program space.

Take a look at the .map file with the data declared as "rom const" and again with
the data declared without the "rom const" and see what section and what address the data is being stored at. I think that will help you understand what is going on.

[Jon236]

That problem went away when we used the latest IFILoader program....also
check here http://www.ifirobotics.com/docs/memory_problem_8722.pdf

Jon Mittelman
Team 236