Variable Initialization too large

DrStu · Feb 14, 2009

Hi all, (using PIC18F4550 with C18 Compiler)

I'm trying to initialize a 2D array variable:

Code:

long testArray[5][32];

and i get this error msg:
Error - section '.udata_GlobalVariables.o' can not fit the section. Section '.udata_GlobalVariables.o' length=0x00000280

I've done searching at its sth like i dun have enuf program memory/RAM/ROM to INITIALIZE this variable.

So i'm juz wondering is there any way around this? ...or is this simply up to its limit......

btw,

Code:

long testArray[2][32];

it works.....anything more than that does not work

kchriste · Feb 14, 2009

A long is 32bits or 4 bytes. So your long testArray[5][32] will occupy 4 x 5 x 32 = 640 bytes of ram which spans more than one bank of memory. Try declaring the variable as far and access it with a pointer:
EDIT! From the c18 getting started guide:

FAQ-10 How do I create a large object in data memory (> 256 bytes)?
By default, MPLAB C18 assumes that an object will not cross a bank boundary. The
following steps are required to safely use an object that is larger than 256 bytes:
1. The object must be allocated into its own section using the #pragma idata or
#pragma udata directive:
#pragma udata buffer_scn
static char buffer[0x180];
#pragma udata
2. Accesses to the object must be done via a pointer:
char * buf_ptr = &buffer[0];
...
// examples of use
buf_ptr[5] = 10;
if (buf_ptr[275] > 127)
...
3. A region that spans multiple banks must be created in the linker script:
- Linker script before modification:
DATABANK NAME=gpr2 START=0x200 END=0x2FF
DATABANK NAME=gpr3 START=0x300 END=0x3FF
- Linker script after modification:
DATABANK NAME=big START=0x200 END=0x37F PROTECTED
DATABANK NAME=gpr3 START=0x380 END=0x3FF
4. The object’s section (created in Step 1) must be assigned into the new region
(created in Step 3) by adding a SECTION directive to the linker script:
SECTION NAME=buffer_scn RAM=big

DrStu · Feb 15, 2009

thx for the quick reply kchriste!

I've downloaded the "C18 getting started" file and tried understanding it...

ill try it out now and get back here...THX
EDIT: IT WORKS NOW!!! YEAH! ...thx kchriste!

DrStu · Feb 15, 2009

A diff "error" encoutered now........

Code:

#pragma idata array_green
	far unsigned long greenDisplay [1]=
	{ 
    	0xFFFFFFFF,
  	},
#pragma idata

when i try to read the array using a pointer, it reads as 0x00000000 instead of 0xFFFFFFFF....any ideas

kchriste · Feb 15, 2009

Can you post the code showing how you declare the pointer and are accessing the variable with the pointer? Remember that arrays in C start at offset 0 and not 1 so you would use greenDisplayPtr[0] to access the variable you initialized above..

DrStu · Feb 15, 2009

sure :

here is my code:

Code:

unsigned long ArrayTest;

unsigned long *greenDisplay_ptr = &greenDisplay[0];

ArrayTest= *greenDisplay_ptr;

then i try reading ArrayTest but it doesnt match greenDisplay[0].....

kchriste · Feb 15, 2009

That's strange. It should work as you coded it. I pasted your code snippets into MPLAB/C18 SIM and it worked OK for me. If you want, you can zip the project directory, attach it here, and I can have a look at it in it's entirety.

Pommie · Feb 15, 2009

It worked correctly for me as well. The only way I can see that it could fail is if the pointer is somehow a near pointer. Does changing it to far unsigned long *greenDisplay_ptr = &greenDisplay[0]; fix it?

Mike.

DrStu · Feb 16, 2009

Pommie said:
It worked correctly for me as well. The only way I can see that it could fail is if the pointer is somehow a near pointer. Does changing it to far unsigned long *greenDisplay_ptr = &greenDisplay[0]; fix it?

Mike.

i tried adding "far" to both the array and the pointer, doesnt work though ... but thx for helping anyway Mike

DrStu · Feb 16, 2009

kchriste said:
That's strange. It should work as you coded it. I pasted your code snippets into MPLAB/C18 SIM and it worked OK for me. If you want, you can zip the project directory, attach it here, and I can have a look at it in it's entirety.

sure, except that it is abit ......chaotic in da coding ....

anyway juz take a look at:
Global Variables.c --> the array and array pointer is defined there
Interrupts.c --> the array pointer is used/tested here

i know its a mess inside, ask me if theres ath else u need to know bout da coding ....

and seriously thanks ...it is really a great help

shingadaddy · Feb 16, 2009

It's global?
Can you try making it *static* and see what happens..?

Not really familiar with what all you have but is & = address of?
Might try it without that and see if the array name and index is all that is needed.
Might make your complainer..er uh compiler more happy.

DrStu · Feb 17, 2009

shingadaddy said:
It's global?
Can you try making it *static* and see what happens..?

well, i need it as global....coz i have to use it within a few different .c files

Not really familiar with what all you have but is & = address of?
Might try it without that and see if the array name and index is all that is needed.
Might make your complainer..er uh compiler more happy.

yea i wish it was this easy ....but the reason im using a pointer to adress it is becoz i have modified a section of the ram to be >256 bytes, and according to the C18_getting_started document (refer to kchriste's post above) ill need to address the variable using a pointer.....

anyways,i am now splitting to array into multiple arrays that are <256bytes (as an easy way out of this mess) , ....but it's juz the disastifaction of not understanding it actually .....appreciated the help guys ....and if abody can spot da cause of the prob...it would be great!

DrStu · Feb 17, 2009

I've found the problem of it....well at least ONE of its problem i mean haha....

In the linker script file, if i assign the databank to be anywhere within
0x0 to 0x7FF
it works.

If i try assigning it outside of this boudary, say 0x800, then da coding doesnt work.......any ideas anybody? .....thanks

EDIT: ....wellllll saw the datashet and it says that the pic18f4550 has 2048 bytes of ram ........which means 0x0 to 0x7ff?

(but in the memory map, 0x800 to 0xFFF is labeled as "unused" ........so it is...unusable? )

3v0 · Feb 17, 2009

(but in the memory map, 0x800 to 0xFFF is labeled as "unused" ........so it is...unusable? )

The addresses are unused by the hardware. There is no memory associated with it. You can not use what does not exist.

DrStu · Feb 17, 2009

3v0 said:
The addresses are unused by the hardware. There is no memory associated with it. You can not use what does not exist.

yea i get it 3V0....thx ....

ok i guess this is stupid ....but... is there any way to initialize a large variable without using RAM or EEPROM? .....

shingadaddy · Feb 17, 2009

What sort of memory did you have in mind?
Maybe a different flavor of PIC with more ram ?

DrStu · Feb 17, 2009

shingadaddy said:
What sort of memory did you have in mind?
Maybe a different flavor of PIC with more ram ?

i was thinking program memory/flash memory hehe yea i did went searching but theres no larger RAM pic which is direct pin to pin compatible with this, and im rushing this for my sch project and so dont have the extra time for a new development board etc etc...

but ive found another around it...which is to be CONTINOUSLY SENDING data through USB instead of storing them in the PIC.......thx all

kchriste · Feb 17, 2009

Good to see you got it figured out. If you need more RAM and are not too worried about speed, one other solution is some external SRAM like the 23K256 from MicroChip which comes with an SPI interface.

DrStu · Feb 18, 2009

yea guess ill try it out kchriste, using external sram.... but why does the 23K256 operate at 2.7 - 3.6V (and microchip has no other alternatives for 5V)? since im running my PIC at 5v, so i would need another voltage regulator juz for the sram?

kchriste · Feb 18, 2009

Probably too much of a pain if you are running the PIC at 5V because of the extra regulator and level shifting required. There are quite a few PICs now that run at 3.3V and these SRAMs would work well with them.

Variable Initialization too large

New Member

New Member

New Member

New Member

New Member

New Member

New Member

Well-Known Member

New Member

New Member

Attachments

New Member

New Member

New Member

Coop Build Coordinator

New Member

New Member

New Member

New Member

New Member

New Member

Privacy & Transparency

Privacy & Transparency