I faced 'section '.udata_xxx.o' can not fit the section' error and after searching through the net, we actually can create objects larger than 256 Bytes by configure the linker files like below:

DATABANK   NAME=gpr1       START=0x100             END=0x1FF 
DATABANK   NAME=gpr2       START=0x200             END=0x2FF 
DATABANK   NAME=gpr3       START=0x300             END=0x3FF 
DATABANK   NAME=gpr4       START=0x400             END=0x4FF 
DATABANK   NAME=gpr5       START=0x500             END=0x5FF  

These 256-byte regions need to be combined into larger regions to fit the new sections:  

DATABANK  NAME=large_udata  START=0x100  END=0x389  PROTECTED 
DATABANK  NAME=large_idata  START=0x38A  END=0x519  PROTECTED 
DATABANK  NAME=gpr5         START=0x51A  END=0x5FF

If I don't put the word PROTECTED, it can compile. But everytime I put the word PROTECTED, the 'cannot fit error' occurs again. Does this means my firmware really have no memory already?

 

<Pedantic correction> When you build a program generally it happens in two steps:

The compilation where symbolic code (i.e., C or assembly statements) are converted to code blobs, but the address where this code will reside is left blank. Same with variables.

The link step assigns code and variables to specific addresses.

C also has a step ahead of build where symbols are handled by the "pre-processor" (and now you know why it's a pre-processor and not just a processor.")

A program that doesn't build will not be linked.

A program that can be built just fine may not link, depending on several things, mostly having room for all the bits.

</Pedantic correction>

Changing linker scripts is a problem as I can't find a manual for the linker; I believe I've had them in the past when I was doing some PIC32 bootloaders (different PIC and different compiler). So I'm left with "good guesses" based on existing examples... but I tend to get my way.

You note what you did in the linker script, which looks OK to me. You don't say what you did in your code. The code needs a #pragmatic adjustment to use the extended section, and you can only access the memory via a pointer.

Examples are in the C18 User Guide hlpC18ug.chm under "Application: Creating Large Data Objects and the USART"

Also the Microchip Forum has a sticky to FAQ that covers this.

 

<Pedantic correction> When you build a program generally it happens in two steps:

The compilation where symbolic code (i.e., C or assembly statements) are converted to code blobs, but the address where this code will reside is left blank. Same with variables.

The link step assigns code and variables to specific addresses.

C also has a step ahead of build where symbols are handled by the "pre-processor" (and now you know why it's a pre-processor and not just a processor.")

A program that doesn't build will not be linked.

A program that can be built just fine may not link, depending on several things, mostly having room for all the bits.

</Pedantic correction>

Changing linker scripts is a problem as I can't find a manual for the linker; I believe I've had them in the past when I was doing some PIC32 bootloaders (different PIC and different compiler). So I'm left with "good guesses" based on existing examples... but I tend to get my way.

You note what you did in the linker script, which looks OK to me. You don't say what you did in your code. The code needs a #pragmatic adjustment to use the extended section, and you can only access the memory via a pointer.

Examples are in the C18 User Guide hlpC18ug.chm under "Application: Creating Large Data Objects and the USART"

Also the Microchip Forum has a sticky to FAQ that covers this.

I refer to this: http://www.xargs.com/pic/c18large.html
If I don't put the word PROTECTED, it can compile. But everytime I put the word PROTECTED, the 'cannot fit error' occurs again. Does this means my firmware really have no memory already?
Is it that I can fixed anywhere from grp1 to grp7? How do we know where the compiler assigned the other variables?

 

Is your firmware executing correctly when you compile without PROTECTED?

 

Is your firmware executing correctly when you compile without PROTECTED?

Nope. The firmware can't really run correctly. Do you have any idea what to do next?

 

Nope. The firmware can't really run correctly. Do you have any idea what to do next?

Yes. Run it in the simulator and test if memory regions are overwritten. Or if you get the correct constant data.

 

Yes. Run it in the simulator and test if memory regions are overwritten. Or if you get the correct constant data.

So you suggest that I should not put "PROTECTED'?

 

I have looked it up in the MPLAB integrated help on your behalf.

PROTECTED means the linker will not use the memory region unless it is specifically identified in the source code.

I also remember editing the linker script and removing a few PROTECTED statements when adapting the USB stack for a smaller chip.

When there is not enough memory at all, you will get an error message in any case.

For regions larger than 256 bytes a) the device must support it, and b) different assembler code must be produced by the compiler.

There are devices which have 16 bit addressing but normally only the lower 8 bits of the FSR are modified.

You should look at help page 90 (MPLABX 1.90), there is information for data objects larger than 256 bytes.
edit: this is refered to above.

I suggest to create a seperate test program only to make sure you can handle large data objects correctly.
Maybe there are bugs in your code?

 

On second thought it does seem like you've run out of memory. If you can get your project to build without the protected keyword do so and check the Memory Usage Gauge in MPLAB (bottom of View menu in non-X, dunno in X). That will show you exactly how much memory is used.

Then see if your reserved 780 bytes has room.

 

On second thought it does seem like you've run out of memory. If you can get your project to build without the protected keyword do so and check the Memory Usage Gauge in MPLAB (bottom of View menu in non-X, dunno in X). That will show you exactly how much memory is used.

Then see if your reserved 780 bytes has room.

Sometimes regions are reserved for a reason, for instance Stack.

You need to get a feeling somehow about the addressing modes supported, and the addressing modes used, as well memory areas required.

Do you use libraries or any kind of ready made stack (here stack means a software stack, not the push/pop stack, which is used on some PICs).

When things go wrong I always write seperate test programs just to test some technique.

Hope we can isolate your issue.

 

takao has a good point, If you look at the stock link script the debug info goes into gpr3 and the stack into gpr2 or gpr3. Often (meaning that's what I do) the stock script is edited into a custom script.

So the whole link script needs be checked (posted?).