Error - section 'UTIL_LIB' can not fit the section. Section 'UTIL_LIB' length=0x00000

[BookerT]

What does:

Error - section 'UTIL_LIB' can not fit the section. Section 'UTIL_LIB' length=0x00000146

means?

[jgannon]

It means that your program is too large to fit onto the PIC chip. Try defining fewer global variables.

[Astronouth7303]

Or enabling more optimizations. This is what worked for me. (Since it was primarily just the libraries)

[BookerT]

How can I enable more optimization?

[Mark McLeod]

Originally Posted by BookerT

How can I enable more optimization?

In MPLAB

• Project -> Build Options... -> Project
• MPLAB C18 tab
• pulldown categories and select Optimization
• click "enable all"

You can look at the C18 C Compiler User's Guide, chapter 4, page 51 for descriptions about each of the optimaizations that can take place. You can choose to do any combination if you like.

[Fat Alex]

In case it helps anyone else I had the same error when I tried for some massive arrays (ram) for instance:

unsigned int left[254]
unsigned int right[254]

gave me a similar error...

[Mark McLeod]

Originally Posted by Fat Alex

In case it helps anyone else I had the same error when I tried for some massive arrays (ram) for instance:

unsigned int left[254]
unsigned int right[254]

gave me a similar error...

An MPLAB project as it's setup only allows 256 bytes of global variables to be declared within any one project file. There are ways around this limit, but it won't really buy you much since you're limited to ~1350 bytes of ram anyway.

[Fat Alex]

Originally Posted by Mark McLeod

An MPLAB project as it's setup only allows 256 bytes of global variables to be declared within any one project file. There are ways around this limit, but it won't really buy you much since you're limited to ~1350 bytes of ram anyway.

1350 is about 5 times as many bytes... what besides variables takes up that space?

Could you elaborate on "the ways around this limit"?

[Mike Betts]

Originally Posted by Fat Alex

1350 is about 5 times as many bytes...

Please think about your question... What is special about 256?

Does 8 bits ring a bell?

[Fat Alex]

Originally Posted by Mike Betts

Please think about your question... What is special about 256?

Does 8 bits ring a bell?

does it have something to do with addresses?
anyway, my question would still hold if it did, what happens to the rest of the space?

[Mike Betts]

Originally Posted by Fat Alex

does it have something to do with addresses?...

Alex,

Look at the code that Brian posted in this thread: http://www.chiefdelphi.com/forums/sh...ad.php?t=33466

See how the address needed to be split into an 8 bit part and a "high" part?

All memory must be accessible via registers. In most processors, these are 8 bit, 16 pit or 32 bit. To access more memory, you have to "page" (the high part).

It really does not matter if the memory/IO space in inside of the chip or outside, the principle is the same. To get the most out of your hardware, you have to understand your hardware.

The PICmicro® 18C MCU Family Reference Manual is 976 pages long. The MPLAB® C18 C COMPILER USER’S GUIDE is almost 200 pages long. You have to start reading!

The answer depends on the type of memory you are trying to access. For example, try reading section 3.2.4 on page 41 of the latter reference. This pertains only to stack size (dynamic and non-static variables) and explains how to cross the 256 byte barrier for stack allocation...

<arms flailing> DANGER WILL ROBINSON!!! Increasing stack allocation will decrease other allocations and cause your code to really slow down as every reference to (in this case stack) memory must be inspected at run time as to which "page" it is in.

Now the same condescending note I gave in another thread... If you are exceeding memory allocations, you are doing something wrong! I most strongly urge you to look closely at what you are doing.

The 2004 Bobcat user routines spans about 1000 lines of code and required about 500 man-hours to develop. That's 1/2 hour per line. Why? Because you have to understand what each and every line does!

Embedded programming requires thought, planning and hard work. That's why it's called software engineering.

Hope this helps...

[Fat Alex]

Originally Posted by Mike Betts

Now the same condescending note I gave in another thread... If you are exceeding memory allocations, you are doing something wrong! I most strongly urge you to look closely at what you are doing.

Well, in the spirit of explanation, the reason I was wanting so much memory is because, my teams robot turns well, so well that it doesn't go strait. To fix this problem I decided a nice lookup table would be advantageous, so I am writing a program to test the speed of the wheels at all 254 speeds (508 int values to store, though maybe that is to far i could do every other and scale the counts into a char, but that would lose data... anyway that is still a good deal of values(char[254]). then calculate what amount of power to send the wheels for a given joystick value and then finally storing that in eeprom or outputting it to the terminal window so the info could be stored as ROM.

So, I only want extra space for calibrating, the actually program will be much more simple.

[Mike Betts]

Originally Posted by Fat Alex

Well, in the spirit of explanation, the reason I was wanting so much memory is because, my teams robot turns well, so well that it doesn't go strait. To fix this problem I decided a nice lookup table would be advantageous, so I am writing a program to test the speed of the wheels at all 254 speeds (508 int values to store, though maybe that is to far i could do every other and scale the counts into a char, but that would lose data... anyway that is still a good deal of values(char[254]). then calculate what amount of power to send the wheels for a given joystick value and then finally storing that in eeprom or outputting it to the terminal window so the info could be stored as ROM.

So, I only want extra space for calibrating, the actually program will be much more simple.

I recently did the same thing. However, I went about it a different way. I printf outputted data to the TTL RS232 port and captured it in a PC. After the test, the data file was imported into Excel, massaged and I generated a lookup table which was included into the next MPlab project build.

Permanent changes to my code were a few lines of code which are now commented out (pending the next time I need this test done).

Free your mind and other portions of your anatomy will follow...

[Mark McLeod]

Originally Posted by Fat Alex

Could you elaborate on "the ways around this limit"?

Mike gave you the basics. Here's just a little more on the linking aspects.

After your code has been compiled, the MPLAB linker determines how your code gets mapped into the available memory on the physical PIC. The linker is guided by the linker script (18f8520user.lkr) in the project folder that among other things specifies how the PIC ram is blocked out or partitioned.
In the case of FIRST our script sets aside several protected areas for exclusive use by the IFI code and sets aside a block (gpr6) for use as a stack for saving things like subroutine call branch locations, etc. The rest is divided up into blocks of 256 bytes each. You can change how large these blocks are.

In addition to the reference Mike gave you, for more information on the linker script see Chapter 5 of the MPASM User’s Guide with MPLINK and MPLIB

Be careful of course. It can be very hard to debug (and for us to help you debug) any problems you create by mucking with this.