CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

"Out of ROM" error

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
kgng97ccs



Joined: 02 Apr 2022
Posts: 97

View user's profile Send private message

"Out of ROM" error
PostPosted: Tue Jan 03, 2023 3:48 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Jan 03, 2023 4:16 am     Reply with quote

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



Joined: 02 Apr 2022
Posts: 97

View user's profile Send private message

PostPosted: Tue Jan 03, 2023 5:25 am     Reply with quote

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?

Quote:
You could probably save some space by optimising many of the functions.

I guess you are referring to modifying the code in such a way as to optimize it. Could you give me some tips on how to optimize code?

Thank you.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Jan 03, 2023 9:10 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group