You are here

My project is using too much rom and I'm not sure what to do | Cypress Semiconductor

My project is using too much rom and I'm not sure what to do

Summary: 15 Replies, Latest post by samwalsh01 on 03 Sep 2014 03:57 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
user_322064261's picture
69 posts

I am getting the following error when building my project

ERROR: .\ARM_GCC_473\Debug\5-MPU-6050-PSoC-GetGryoscopeValues.elf section `.data' will not fit in region `rom'
ERROR: region `rom' overflowed by 112 bytes

I have attached the bundle, this is all to do with enabling an interrupt, if you look in main at line 54 I have a timer interrupt being enabled. If I comment out this line it builds if I don't then it fails saying rom is overloaded.

I can see I am using 99.7% of Rom and I want to know what I can do to bring this down as there isn't that much code in my project I don't think.


user_14586677's picture
7646 posts

The following are general suggestions for optimizing FLASH code

space usage -






/* Style Definitions */
{mso-style-name:"Table Normal";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman";

These helped me in a similar experience -


1 - If any float math minimize the number of lines you do divides, if possible convert

to multiplies. Convert float to integer math where possible. Pay attention to factoring

of expressions, possible operation reduction, hence code reduction may result.


2 - Lines with function calls, minimize f(g()) compound typed expressions.


3 - Make sure you only use a variable type no larger than needed.


4 - Use unsigned variables wherever possible.


5 - Watchout for structures with mixed const and ram pointers within them,

some compilers choke on this.


6 - If you are heavy on Flash, light on RAM use, convert routines to RAM based

wherever possible.


7 - Try test cases of looping structures, to see what affects code size generation.


8 - Examine .lst file for code that looks wacky in bytes used, understand what

compiler did, and consider rewrite.


9 - Use inline ASM where .lst file C generation looks excessive.


10 - Look at module reuse, sharing, dual purpose, to eliminate # modules 

needed, like counters/timers....Also look at data sheets of modules that could

serve function needed, and compare ROM/RAM requirements needed. Optimize

global HW, like clocks VC1/2/3/Sleep, to eliminate need for other timer/counters.

Use register routing control to "share" module from one task to another, one pin

to another.


11 - Extended library, functions within them are written to be perfectly general,

hence larger code size, you may be able to write one with less code needed for

your specific requirements that result in smaller code size.


12 – Look for approximations to compute transcendental functions if used.


13 - Although no longer supported by HiTech or Cypress, the HiTech Pro compiler

yielded on first try ~ 40% code reduction in my design when I first converted

to it. Then the prior comments yielded another 4 K later in design as I was up

against 32 K Flash limitation.


14 - Some compilers have a setting to optimize code size or speed, the latter

prone to larger code size. Also look at compiler vendors web site for ap notes

and suggestions on optimization, compilers from different vendors behave and

optimize  differently.


15 - const data, strings, etc.., look for ability to reuse common string mnemonics,



16 - Pointer usage can lessen code size, see url's below. Look for function calls

passing longs as value vs pointer, convert to latter. Compiler has to copy all these,

if not referenced. Do not pass longs or floats as values, keep always in mind native machine size.


17 - Most compilers will optimize when indexes, pointers, a power of 2, or divides,

divide becomes a shift.


18 - Look at how linker distributed code and data segments, sometimes you can discover

a poor decision by linker and force code/data into certain psects using pragma constructs,

thereby minimizing wasted ROM space.


19 – When you debug generally you want to turn off optimization, as compiler/linker will

remove code and make jumps that do not make “sense” but are the result of optimization.

When you are up to Flash boundary you may not be able to turn it off, otherwise

application will not load. Keep this in mind, that  your debug strategy may have to change.

I also found if using ICE Cube that debugger may no longer report “watch” variables, this

occurred at ~ 31.5K bytes. In either case you may want to comment out large code sections

to effectively debug.


20 – f() calls take overhead, if you only call a f() once you might eliminate it as a f() call and

place code inline.


21 – Look for f() opportunities, wherever you are coding and repeating similar  operations.

This is obvious, but sometimes missed.


22 – Check compiler on macros, to see if they are being optimized or just being used inline

using more code space vs a f() call solution.


23 – Examine compiler/linker parameter control. For example in HiTech there is the AUTOBANK

setting that controls where local variables are stored, in my case setting to 1 lowered code size by

~ 250 bytes. READ the MANUAL !


24 – Use inline variable declarations, vs pre declaration (compiler dependent) -


                This                        void dosomething ( void  ) {


                                                                for (  unsigned char I = 0;…..



                Not This               void dosomething ( void  ) {


                                                Unsigned char I = 0;


                                                                for (  I = 0;…..



Some help -








By using these techniques I was able to regain ~ 4K Bytes of code space in a 32K design, which

I promptly then used up again :(


Regards, Dana.

user_1377889's picture
9307 posts

As I learnt recently you may set optimization level for each of the .c files separately. Since optimization hinders debugging you can start by setting tested portions of your project to optimize for size.


DO NOT USE printf() !! The overhead is more than a PSoC4 can swallow.


Just for curiosity: What does your project perform? Quad copter??



user_14586677's picture
7646 posts

I turned on size optimization in build settings and got -


Flash used: 29268 of 32768 bytes (89.3 %).
SRAM used: 2028 of 4096 bytes (49.5 %).


Regards, Dana.

user_1377889's picture
9307 posts

I just compiled your project successfully be setting "Release" mode and adding "m" to the libraries in release mode settings.

Using 22kB, leaving 10kB for the rest of your program.



user_1377889's picture
9307 posts

Dana, that is interresting! Why could I use only 22kB???


Flash used: 22008 of 32768 bytes (67,2%).

SRAM used: 1972 of 4096 bytes (48,1%).

--------------- Build Succeeded: 09/01/2014 19:20:23 ---------------

user_49271930's picture
408 posts

How to safe  optimize (reduce)  xxx.cydvr ->system->HeapSize and StackSize?

StackSize=0x0200:   SRAM used: 1460 of 4096 bytes (35,6 %).



user_14586677's picture
7646 posts

Odd, i have same settings, m, release.


No idea whats causing this.


Regards, Dana.

user_49271930's picture
408 posts

Dana, maybe you have added something else in settings like this:

Project-> Build Settings-> ARM GCC 4.7.3-> Linker-> Command Line. Add “-u _printf_float”

Flash used: 29244 of 32768 bytes (89,2%).

SRAM used: 2028 of 4096 bytes (49,5%).

user_14586677's picture
7646 posts

Thats it Pavloven, I did have that linker directive.


Regards, Dana.

user_322064261's picture
69 posts

I owe both of you a beer, you have got me out of so many tight spots!

Bob my project will eventually be a quadcopter controller using a Raspberry pi on wifi and a  PSoC doing all the nitty gritty. I am going to remove as much of the printf's as possible I didn't know Creator had an optimize ability. thanks so much

Log in to post new comments.