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.

How do I use the linker to move code into RAM?

Other Parts Discussed in Thread: MSP430F5328

I am trying to have some of my code execute from RAM so I can eek out the little bit of power savings that I've heard it can offer (or, at least, measure for myself how much it actually saves)

I opened up the 'lnk_msp430f5328.cmd' file that was created by CCS when I created the project, and I changed 

    .text       : {}>> FLASH | FLASH2     /* CODE                              */
    .text:_isr  : {} > FLASH              /* ISR CODE SPACE                    */
to
    .text       : {}>> RAM | FLASH | FLASH2     /* CODE                              */
    .text:_isr  : {} > RAM              /* ISR CODE SPACE                    */

The code runs right after the chip is programmed, but after power is cut and restored, the module seems not to run anymore.  I'm guessing that the code that was stored in RAM was lost because RAM is volatile and looses it's contents when it looses power.  If that is what is happening, it surprises me because I would have thought that it would be saved in FLASH, but loaded to RAM during power-up. I'm under the impression that that happens with the .data section.

Is that what is happening? Is there something I can do to the linker to make it load the code to RAM during power-up like I thought it would anyway?

  • An update.

    I put the lnk.cmd file back to normal, and started messing with #pragmas

    I added a pragma to the adc interrupt so that it would be loaded into the .data section.  Now my isr deceleration looks like this.

    #pragma CODE_SECTION(ADC12_ISR, ".data")
    #pragma vector = ADC12_VECTOR
    __interrupt void ADC12_ISR(void) {

    I observe exactly the same behavior as before.  All seems to be well right after the chip is programmed, but then after cycling power, it won't run at all.

    I'm beginning to think that it's not just RAM being lost, because after power up, I flash an LED before I enable interrupts.  After cycling power with a single ISR in RAM, it won't even flash that LED for me.

    Please help me understand what's going on here.

  • Luke,

    if you are using CCS, you need to explicitly copy the binary from flash to RAM in your code manually. Please refer here.

  • Luke Davidson2 said:
    The code runs right after the chip is programmed, but after power is cut and restored, the module seems not to run anymore.

    You told the linker to output a binary where the code is located in ram. So the code is uploaded to ram and is lost if power is gone.
    If you want th ecode to be persistent, you mus ttell the linker to link the code as if it were placed in ram but put a copy into flash so it can be copied from there to ram at power-up. Just like the init values for your global variables.

    Leo has pointed you to the right thread.

  • "If you want the code to be persistent, you must tell the linker to link the code as if it were placed in ram but put a copy into flash so it can be copied from there to ram at power-up. Just like the init values for your global variables."

    This is what I need to do ^^^ The examples are all chopped up throughout the CCS v6 "Help" section.

    I just need to do this so I can start my embedded project board on its own, without IDE etc.

    If you can point me to a link, that would be awesome.

  • Leo has given you a link to a thread dealing with this.
    However, another possible solution is to add an attribute to the function that puts it into the initialized data section. In this case, the linker will reserve space for the function in ram, and the C startup code will copy the function from flash to ram like it does for the init values of your global variables. You can even call the function by name as if it were in flash.
    The only problem is: ram functions are sensitive to being overwritten by out-of-bounds array writes or stack overflow. While neither of the two should ever happen in a proper program, both do - and bugs by executing partly overwritten code are difficult to debug.

**Attention** This is a public forum