This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS ram/ flash bugs C2000 piccolo 28069 out of RAM

Other Parts Discussed in Thread: CONTROLSUITE

how do i know if I am doing RAM programming or flash programming ?

I had a certain code that was compiling. It was working ok. Then I added some more variables (6) it started crying about being out of RAM. I tried reducing code by removing some functions but to no effect. I agree there were plenty of arrays in my code. I removed 3x 50 arrays of size 16 and made them into 6 arrays of size 12. I am sure that must have saved a ton of RAM.  2328 bytes shud be saved

Then I added 2 more 50 size arrays . so total saved 2228. Everything was working great at this point of time.

All arrays are floats

Now I added one more 6 size array and it started crying all over again.

I am totally confused. it just doesnt add up.

pls help.

If the code size is problem to fit in RAM ,reducing code shud help but it doesnt.

  • Hi Anusheel,

    anusheel nahar said:
    how do i know if I am doing RAM programming or flash programming ?

    It depends on the linker file configuration. If you've a look in your project, you might find a .cmd file. Here's how you can identify: RAM : 28069_RAM_lnk.cmd & FLASH: F28069

    Also, while debugging when running through RAM, the code loads very quickly but with flash it takes around 5-10sec.

    anusheel nahar said:

    Then I added 2 more 50 size arrays . so total saved 2228. Everything was working great at this point of time.

    All arrays are floats

    Now I added one more 6 size array and it started crying all over again.

    I am totally confused. it just doesnt add up.

    Yup, when running through RAM you've memory constraints for heavy array sizings and numbers. Hence, flash is preferred for complex and long array computations.

    You can try implementing the same array computations by importing this example code from controlSuite:

    C:\ti\controlSUITE\device_support\f2806x\v136\F2806x_examples_ccsv5\flash_f28069

    This code runs through flash and hence has the cmd file configured accordingly.

    Regards,

    Gautam 

  • My observations imply that there is something absurd abt TI compiler /CCS etc.

     its like bucket is full because I cant add more stuff.                      

    But I removed a ton of stuff but still if I add 0.5 % of the stuff I removed the bucket still becomes full. This is absurd. 

    Also there has to be a better way to change from RAM to flash without changing cmd file. It shud be in GUI i remember seeing it (selecting flash/RAM) but cant find it now. 

    Even if i use this flash code it doesnt help me because my code will not go to flash by running the above code.

  • Forwarding your query to a CCS expert.

    Regards,

    Gautam

  • anusheel nahar said:
    My observations imply that there is something absurd abt TI compiler /CCS etc.

     its like bucket is full because I cant add more stuff.                      

    But I removed a ton of stuff but still if I add 0.5 % of the stuff I removed the bucket still becomes full. This is absurd.

    For C2000 devices the linker command files split the RAM into a number of "blocks", which means with the default linker command files when a new CCS project is created can cause insufficient memory errors to be reported by the linker even when there is free space in other memory blocks.

    The solution is to edit the linker command file to adjust which sections are allocated to which memory blocks.

    I agree that CCS doesn't make it obvious how to correct such linker errors.

  • The compiler will also block global arrays across data pages, in order to improve DP load performance.  To determine whether this blocking could be the reason why your data doesn't fit, try disabling the blocking optimization with the --disable_dp_load_opt (or -md) flag.  Performance would likely suffer too much for this to be a practical solution, but it could indicate whether the data page blocking is a factor.  You can also look at the memory map file to see how your arrays are laid out across the data pages.

  • Please consider the technique described in this forum post.  It avoids the memory holes caused by blocking, while avoiding most of the runtime costs.

    Thanks and regards,

    -George

  • I tried changing the cmd file to F28069 ....and the code which was barely running now cries it cant fit into memory. : ( 

  • i also tried adding the memcpy and initflash as given in the example link you gave . Same result.     I am clueless how is memory organized inside TI.

    How can code fitting in RAM cry that it cant fit in flash when flash is 100 times more than RAM ?                                        totally whacked out. :(   ..............I think in any projects there is like tons of stuff which only ends up confusing the user. includes ,debug binaries other non sense (which an apps engineer doesnt have to worry about) etc but things which are of absolute necessity like doing flash programming are totally messed up. Also everything is in diffrent directories. there is workspace in user , there is example ,there is common then my application file then there are versions for each processor ....

    Now someone will say I need to change some page boundaries etc ...but its too confusing and too risky for app engineer as it goes into unchartered territory.  I wonder without flash programming (or so confusing) how is TI even able to sell a single micro/dsp  ?

     

  • Please post your linker command file as attachment.  You'll probably have to add the extension ".txt" to it.  And describe where you got it.

    Thanks and regards,

    -George

  • C:\ti\controlSUITE\device_support\f2806x\v136\F2806x_common\cmd

    pls find attachment here.... i dont know how to attach the file

    https://dl.dropboxusercontent.com/u/31828930/F28069.txt

  • I think it will help if you understand how a C variable ends up occupying space in system memory.

    Consider this example code ...

    /* global variables */
    int val;
    const int const_val = 20;
    

    Presume this code is built with large memory model, a long standing standard for C28x projects.

    Now look at the section titled Sections in the C2000 compiler manual. You will read that val goes in the .ebss section, and const_val goes in the .econst section.  Now consider these lines copied from the linker command file ...

      .ebss               : > RAML2,      PAGE = 1
      /* ... */
      .econst             : > FLASHA,     PAGE = 0
    

    The first line says collect together all the .ebss input sections from the individual object files and library modules, combine them into an output section also named .ebss, then allocate that section into the RAML2 memory range.  A similar process is used for .econst and FLASHA.  

    You can see how changing variable definitions can change the section and memory range which contains them, and thus affect your memory map.

    I hope that, based on this understanding, you can work out what has gone wrong and fix it.

    Thanks and regards,

    -George