MATH_DATA can not fit the section

[neutrino15]

Hello,

The c18 compiler is returning an error

Error - section 'MATH_DATA' can not fit the section. Section 'MATH_DATA' length=0x000000014

The hex file last time it compiled is only about 40K, so I don't think overall size is an issue. All I did since last compile (successful) was add one more global int and another if statement.. Nothing too drastic..


Any help would be appreciated!

[psy_wombats]

In the unlikely event those two changes caused the error, have you reverted and tried to intentionally eat memory? If it cuases the error again, that's the issue, obviously. Global variables do consume a fair amount of memory. Otherwise, I'm at a loss. Maybe it's that a single object can't occupy too large a memory chunk?

[Daniel Bathgate]

If a giant static array is causing the problem like it was for me, try using the C18 keyword "rom" in the decleration (the microchip C is not pure ANSI C and has additional keywords) to let the compiler know the array can go in program memory.

[neutrino15]

I added a global short.. What is odd, is when I comment out this block of intense-ish math code, it compiles.. This is weird. The only variable defined there is 1 float. The only other globals besides kevin watson's declarations is one struct with a few longs and a few unsigned ints. It certainly does not seem like I am overloading anything. Do too many equations overflow memory like this?

EDIT:
How do I enable ROM? I am using linux with the adambots makefile, but I can give args to mcc18 if need be. How did you do it?

EDIT2:
I changed 2 LOCAL longs into ints and it COMPILED... Why is this?!?!?!?

[Chaos in a Can]

From what I can tell, it gives this error when you try to allocate too much memory to one section.
I have no idea how much memory one section can use, or even what one section is, but if you stick stuff into rom or use smaller types, you can probably get rid of this error.

You can also try giving the "-mL" argument to C18 to tell it to use more memory.

I don't believe operations of any sort contribute to the problem, as that is all stored in rom.
Changing the two longs to ints would reduce the amount of ram it needed. Even though they are local, they have to go somewhere when other local variables are still in scope.

You can use "rom" like a variable modifier.

rom static variable;

I'm quite suprised "const" doesn't put stuff in rom, and I would expect that "rom" makes data unchangeable just like "const".

[Mark McLeod]

It only takes one byte to over stuff available memory if you're close to the edge.

The size of your hex file is not directly related to the amount of memory you are using. Generate a link map if you want to see how much you've used up.

Intense math can load extensive math libraries.
The use of floats in the non-floating point processor we use requires extensive overhead to do the simplest floating point operation.

[neutrino15]

Hey,

I think that I was pushing the limits of the variable section of memory. I changed the entire trig array to rom, and re-used variables whenever possible. It now compiles smoothly! (Generating a 65K hex file!)

Thanks for your help!

[Alan Anderson]

Originally Posted by neutrino15

...I changed the entire trig array to rom,...

I think predefined constant arrays like that should always be placed in rom unless you have a good reason not to to it. Back when I was looking into such things a few years ago, I remember discovering a limit of only 256 bytes of global variables for each code module. A single lookup table can easily fill that.