1 2 Previous Next 15 Replies Latest reply on Jan 15, 2014 8:48 AM by user_14586677

    ADDRESS SPACE OVERFLOW CONST

    nilesh.tekale

      Hi all,
      I'm looking for some memory optimization.
      at one stage I build my project and it shows my memory mapping as

      Program Size: data=22.0 xdata=3506 const=5803 code=16419
      ERROR: L107: ADDRESS SPACE OVERFLOW CONST ?CO?MAIN 0000BEH
      ERROR: L120: CONTENT BELONGS TO ERRONEOUS SEGMENT ?CO?MAIN

      Now if I remove few lines from my code it reduces 18 BYTES as
      Program Size: data=22.0 xdata=3506 const=5803 code=16401
      Flash used: 22204 of 32768 bytes (67.8 %).
      SRAM used: 3506 of 4096 bytes (85.6 %).
      It means no change in memory other than code memory so why the error is overflow from const memory.
      and if we consider about code memory then yet 10546 BYTES are free to use.
      Is there any relation with no. of components used in topdesign and the flash memory we can use.

        • 1. Re: ADDRESS SPACE OVERFLOW CONST
          user_14586677

          Beforfe Imagecraft Pro was released I experiened a 40% code reduction

             

          using HiTech, which is no longer offered/supported (other than other

             

          users, psocdeveloper.com).

             

           

             

          I did extensive code reduction on a 29466 to fit my application, and the

             

          below is what I did to achieve this.

             

           

             

              

             

                    

             

          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,

             

          text.

             

           

             

          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) -

             

           Note note supported in Imagcraft

             

           

             

                          This                        void dosomething ( void  ) {

             

           

             

                                                                          for (  unsigned char I = 0;…..

             

                                                          }

             

           

             

                          Not This               void dosomething ( void  ) {

             

           

             

                                                          Unsigned char I = 0;

             

           

             

                                                                          for (  I = 0;…..

             

                                                          }

             

           

             

          Some help -

             

           

             

          [url]http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization[/url]

             

           

             

          [url]http://www.eventhelix.com/realtimemantra/basics/optimizingcandcppcode.htm[/url]

             

           

             

          [url]http://www.azillionmonkeys.com/qed/optimize.html[/url]

             

           

             

          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.

          • 2. Re: ADDRESS SPACE OVERFLOW CONST
            ki.leung

             I think the issue is with the Keil compiler for PSoC3 not PSoC1, but some of your suggestions is still valid.

            • 3. Re: ADDRESS SPACE OVERFLOW CONST
              ki.leung

               I didn't have the spec on hand, but that seems to be at the lower end of the flash address which seems to be around the interupt vector area. 

                 

              May be upload your code here so people can check as well

              • 4. Re: ADDRESS SPACE OVERFLOW CONST
                user_78878863

                Constant data (such as string constants) go to flash, like code does. So if flash memory size is not sufficient to place both, it seems to report that the const data cannot be placed. But either reducing the code size or the data size will help you here.

                • 5. Re: ADDRESS SPACE OVERFLOW CONST
                  ki.leung

                   0BEH is around the end of the jump vector. And I think the default starting address of code is at 100h. 

                  • 6. Re: ADDRESS SPACE OVERFLOW CONST
                    user_14586677

                    My error on Imagecraft/HiTech post, however many of the suggestions apply.

                       

                    Additionally try simple tests to see what Keil will do in terms of code density.

                       

                    If you are up against FLASH size barrier you will be surprised how simple

                       

                    changes to code can produce modest, but importent savings in code size.

                       

                    Especially using pointers for non native variable sizes.

                       

                     

                       

                    Regards, Dana.

                    • 7. Re: ADDRESS SPACE OVERFLOW CONST
                      ki.leung

                      Upload your project, so people can check. That is the faster way to solve your issue.

                      • 8. Re: ADDRESS SPACE OVERFLOW CONST
                        nilesh.tekale

                        Hello H L,

                           

                        I have attached my project here. and my application is not completed yet, so lot much is there to add.

                           

                        But I wish to know meaning of your statement in deep [0BEH is around the end of the jump vector. And I think the default starting address of code is at 100h. ]. Please tell me where I can get its detail description?

                           

                         

                           

                        and Thanks to all for replying.

                        • 9. Re: ADDRESS SPACE OVERFLOW CONST
                          nilesh.tekale

                          I tried again to upload

                          • 10. Re: ADDRESS SPACE OVERFLOW CONST
                            nilesh.tekale

                            My project is not uploading. It is in .zip

                            • 11. Re: ADDRESS SPACE OVERFLOW CONST
                              user_78878863

                              When attaching files don't use Chrome. Use IE or Firefox.

                                 

                              Regarding your question: you can look at the Technical Reference Manual (TRM), there shiould be a memory map in there. And there you can see which stuff is in certain memory locations. But I guess it doesn't really matter, since the linker just complains that the code is too large.

                              • 12. Re: ADDRESS SPACE OVERFLOW CONST
                                nilesh.tekale

                                I am trying it in firefox

                                • 13. Re: ADDRESS SPACE OVERFLOW CONST
                                  ki.leung

                                   Try IE, it should work.

                                  • 14. Re: ADDRESS SPACE OVERFLOW CONST
                                    nilesh.tekale

                                    OK now I tried it by IE

                                    1 2 Previous Next