• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 1645 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/TMS320F28069: ram function and memcpy()

Arash Tahghighi
Intellectual 620 points
Part Number: TMS320F28069

Tool/software: Code Composer Studio

Hi

Example_2806xLaunchPad demo project I was trying to figure out how memcpy() work. and what exactly it does.

from the .map file I learned the only function is runing in RAM is DSP28x_usDelay. am I right?

I commented out the memcpy() and didnt see any change in .map file. can anyone tell my why?

thanks

  • 0
    TI__Guru* 77510 points

    Arash,

    The memcpy() function is used primarily to copy contents of flash to RAM so that it can execute at a faster overall speed(Flash cannot run at 0 WaitState 90MHz, but RAM can).  Alot of projects have 2 build options, one for RAM and one for FLASH.  If your project is using the RAM option, then the code is loaded directly to RAM, vs programmed to flash and there is nothing to copy.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 620 points

    memcpy() is to copy flash content to RAM??  you mean all content of flash? I took a look at .map file 

    memcpy() only copy 4 bytes(words). 

    where is that build option u talking about?

    doesnt make sense , can you or anybody give more specific answers instead of general things?

    thanks

  • 0 in reply to Arash Tahghighi
    TI__Guru* 77510 points

    Arash,

    The majority of code is still running from Flash(that is the default build option).  The reason that the usDelay is copied is that it needs to run from 0 WS memory(RAM) to give an accurate cycle count across device settings.  This function takes an interger value of how many micro seconds of wait time is needed, and translates it into CPU cycles.

    The reason that the map file doesn't change is that it is based on the cmd file only, and in the cmd file the usDelay function has been allocated as a load to flash, but run from RAM.  It is the responsibility of the program code to execute the memcopy() before the usDelay function is called so that it will be in the correct RAM location when it is called during operation.

    My earlier point is that there could be other run time critical code that a user would want to move to SRAM from Flash, and memcopy would take care of that as well.  In this case the usDelay() function is all that is considered time critical for the reasons above.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 620 points

    Hi 

    Thanks for your reply and your comment, it was helpful.

    A new question came to my mind. If I would like to run my ISR from RAM, what exactly should I do beside memcpy().

    I would appreciate if you give me details and steps.

    Thanks

  • 0 in reply to Arash Tahghighi
    TI__Guru* 77510 points

    Arash,

    This example http://dev.ti.com/tirex/explore/node?node=APornO3AeJgkKmOcBwzgnw__gYkahfz__LATEST shows how to do that, the main code is loaded/executed from flash, but the ISRs are copied and executed from RAM.  You'll see the forced mapping via a pragma in the main code, and then the memcpy will push it over.

    Best,

    Matthew