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.

TMS320F28032: How can I load a program running in RAM into two non-contiguous RAM space?

Part Number: TMS320F28032

In our project, the interrupt program runs in RAM, but the memory of the current single RAM space is not enough, we need to combin 2 RAM spaces to fill the program, but CCS seems to prevent my multi-RAM space combin

what should i do to achieve my purpose?above is just a example, tks

  • In the .cmd file you can manually combine the ram files into one continuous space like:

    RAML0L1 : origin = 0x008000, length = 0x001000

    Then just assign the RUN to the new unified RAML0L1.

    Best,

    Matthew

  • Sorry, we can't do this, because in our mass-produced products, the middle RAM space has been used in the user's BOOT area and cannot be changed, so it is impossible to manually merge the two RAM spaces. Is it possible to combine two non-contiguous RAM spaces for ISR operation?

  • I believe the issue is that the linker will throw this error if a section spans the memory union as you have it in your original post. 

    You would need to break up the code into different code sections so that the linker can be directed to place them in different RAM regions.  Is this something that is possible to do in your project? 

    So instead of one "ramfuncs" code section/pragma you would need to experiment with dividing the code you want to execute from RAM into multiple code sections.

    To make sure that this will all fit, even if you can't use a continuous region could make a "fake" memory section that is the same total size as the RAM you do have, to make sure that it will fit before you start to break it up.

    Best,

    Matthew

  • thank you!  I understand the method you are talking about,We have also thought of your idea, but we can't do it, because the running program is an interrupt program. If the interrupt program is divided into multiple functions, the efficiency of function calls will be very low. At present, we have one function for the entire interrupt code.
    I would like to know if there is a way to achieve this in terms of CMD file configuration

  • I'm going to loop in a few more folks from the SW side to see if we have a CMD soln that doesn't involve manually moving things around.

    Best,

    Matthew

  • Try and add this compile option: --gen_func_subsections   This will break up your existing functions so they can be spanned across the unions.

    Best,

    Matthew

  • seem not work,It seems that the “run” command in cmd file does not support the syntax of "|",We need to run into non-contiguous RAM space,flash is OK

  • Can you comment on the optimization settings in the compiler as well as let me know which(if any) libraries you are including in the project?

    Is your project including the Flash API library, specifically?  There is an option to link this to ROM(already programmed by TI) to save space.

    At this point I'm trying to see if we can just reduce the overall code footprint as I don't think we have any other options to try and re-allocate things.

    Can you attach the full .cmd file for me to check the allocations as well?

    Best,

    Matthew

  • Ok, we just wanted to know if there is a way to solve this problem at the CMD file configuration level, since it is not possible to "RUN" to 2 non-contiguous regions, we have tried to optimize the code. thanks

  • Foriner,

    I got some more info from our tools team on the above.  It looks like we need to change the RUN statement to(replace = with >>):

    RUN >> RAML0 | RAML1

    This will make the linker span the function.

    However, this will cause a new issue, and that is for the copy of the function from Flash to RAM since that function operates on a contiguous assumption.

    To fix this we need to make a copy table, vs using symbols. So now we have

    .TI.ramfunc     :  LOAD = FLASHH,

                               RUN >> RAML0 | RAML1

                               table(BINIT)

                               PAGE = 0

     .binit > FLASHH

    This "binit" section will be handled by the RTS library before main and copy thing correctly.  Let me know if this has any issues.

    Best,

    Matthew