MPLAB 8.0 error "Can not fit section"

Technical Programming
1

I am getting the following error when compiling some code:

MPLINK 4.1 Linker
Copywrite...
Error - section '.udata_bob.o' can not fit section. Section ' udata_bob.o length= 0x00000158

I have a feeling it may be caused by my “bob.c” file, we do declare 3 two dimensional arrays in it. Each one is declared like this: “int name [11][5];”

Is this more than MPLAB can handle???

2

If I remember correctly, the PIC can’t have more than 256 bytes in one memory segment. 2x11x5x3 will be 330 bytes, which is too big. You’ll have to use a #pragma statement to put each array into its own chunk of memory. Take a look at section 2.9 of the C18 manual.

3

386 had this problem…

our solution was changing some static variables to non-static, or making them global.

I apologize in advance for the lack of verbose response, I’m recovering from the all-nighters.
–Chris

4

Steve and Chris,
Thanks for the replies, I had a feeling it was something like this. I will see if I can find a different approach.

All nighters are probably why I tried something like this in the first place.:slight_smile:

5

You could also break those declarations into separate files.

6

If your arrays are tables of constants, you can put them into the much-less-limited ROM by:

**rom const** int name [11][5];
7

That would be difficult, but not impossible. We use all three arrays in our Autonomous navigation code. It would be more of an inconvenience than anything else. I believe I found the reason we were having difficulty that made me try this approach. I had initialized an array as a LONG, but tried to dump ints into it without any indication they were ints. (In fact, I don’t even know the correct way to do this, but I know it exists.:mad: ), I then called the data out without typecasting the values as ints. What I got was garbage. I re-declared the array as an int array, that should fix the original issue.

I thought of this, but I am not comfortable enough in it’s use to do this without building and loading it to test. (The bot is shipped now.)

Thanks to both for your input. These are both techniques I/we should master in the off season. Thanks for adding to our list of things to learn!!!

8

This is a linker default limitation. There is a method for supporting stacks > 256 as outlined in the MCC18 user guide, it involves merging multiple banks of registers. This seems to work for variable space too, but there may be limitations I’m unaware of. The code would need to be thoroughly reviewed and tested but this should work as I’ve seen it used on other PIC projects.

In the linker file, change:


DATABANK   NAME=gpr6       START=0x600          END=0x6FF
DATABANK   NAME=gpr7       START=0x700          END=0x7FF

to 

DATABANK   NAME=gpr6       START=0x600          END=0x7FF
//DATABANK   NAME=gpr7       START=0x700          END=0x7FF

This merges two banks into one available segment. There are run-time costs associated with doing this so it isn’t recommended practice.

I built three int [11][5] arrays and got the same linker error. Then I merged the banks and did it again and it will link. I poked at some of the arrays with C code and looked at the machine code – it looks correct.


int vars1[11][5];
int vars2[11][5];
int vars3[11][5];
void testtest1( void )
{
static int var;
static int *ptr;
static int row,col;

    var = vars1[4][3];
    var = vars2[8][4];
376:                   var = vars3[3][1];
 05762    C6FF     MOVFF 0x6ff, 0x74d
 05764    F74D     NOP
 05766    C700     MOVFF 0x700, 0x74e
 05768    F74E     NOP
377:                   var = vars3[3][2];
 0576A    C701     MOVFF 0x701, 0x74d
 0576C    F74D     NOP
 0576E    C702     MOVFF 0x702, 0x74e
 05770    F74E     NOP

    var = vars3[6][2];
    for (row=0; row<11; row++)
        for (col=0; col<5; col++)
            var = vars2[row][col];
    ptr = &vars3[0][0];
    var = *ptr++;
}