"Out of ROM" error

[kgng97ccs]

I am using the PIC18LF46K22 MCU, CCS C compiler v5.113, and MPLAB IDE v8.92.

Today I encountered the following error message:

*** … Error 71 "F:\A\_Data1\Programming\SMN-828B_Code\main_N828B_v1.c" Line 271(1,2): Out of ROM, A segment or the program is too large MAIN Seg 00194-0FFFE, 0102 left, need 005E8
Seg 00000-00002, 0000 left, need 005E8 Reserved
Seg 00004-00006, 0004 left, need 005E8
Seg 00008-00192, 0000 left, need 005E8 Reserved

Line 271 is the last line of the main program (the last closing curly bracket).

My main program has a main header file containing preprocessor directives and global variables; the directives include many #include directives for .c files containing c functions. The main program has been compiling without any “Out of ROM” error until today. Although I have been adding functions (in .c files) from time to time, these added functions have fewer statements than previous functions that compiled without this error, so I am puzzled what is causing the problem.

I searched the ccsinfo forum and understand that one solution is to split the code into smaller parts.

Questions:
1. Should I go back to those earlier functions that are relatively bigger and break them up into smaller functions, even though those earlier functions did compile without “Out of ROM” error earlier?
2. Is there any way to tell from the error message which functions are causing the problem, so that I can focus my efforts on those functions?
3. What kind of statements will tend to make a function “bigger” (fprintf statements, for example)?

I will appreciate any ideas on where I should start. Thank you.

[Ttelmah]

Have you got the last program version that compiled (hint the __history
directory has older versions).
Compile this.
How big is the resulting program?. How much space is left?.
The program may simply have got too large for the chip.
The messages you post suggest this.

The splitting up thing applies where the Seg figures are saying that the
code is too large to fit into a single segment, when there is space still
left in the other segments. Your result does not show this.

You could probably save some space by optimising many of the functions.
You could also try compiling with the COMPRESS option on #OPT. This
optimises for space, and might get it in.

[kgng97ccs]

Thank you so much, Ttelmah, for this tip.

I placed "#opt compress" at the top of the main program, and the code compiles without any error! (the #opt1 to #opt9 did not work)

The manuals says that with the compress option, "the code is optimized for space, not speed. Debugging with this level my be more difficult."

Questions:
1. In what way will the debugging be more difficult?
2. To what extent will the speed be affected?
3. Are there any other trade-offs and how bad will they be?

[Ttelmah]

Very basic things.
For example, if you are doing basically the same job in
two different places, making this into a separate routine, and then calling
this single routine (especially if you declare this as #SEPARATE, to avoid
the compiler by default 'inlining' small routines, will save space.
This is what the COMPRESS will switch. By default, small functions will
not be called as subroutines, instead the compiler will make a separate
copy each time these are called. Now when debugging, you step through
the code and can see that this is inside the main code where it is called.
However with COMPRESS selected the compiler instead makes this a
called subroutine. If you 'break' inside this, you can't tell which of the
calls you actually got there from.