• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 758 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/MSP-EXP432P401R: Problem when executing code from RAM(when compiling the project with --ramfunc flag).

Anton Proskurnin73136
Prodigy 60 points

Part Number: MSP-EXP432P401R

Tool/software: TI C/C++ Compiler

When specifing --ramfunc option for compiler, the program fails to run and it stucks in the Reset_Handler function constantly, like being restarted every time.

Without this flag, the program runs just fine(executed from flash as normal).

I am using standart example from Simplelink SDK(Simplelink MSP432P4 SDK - v:3.10.00.08):

msp432p401x_1_MSP_EXP432P401R_nortos_ccs. Blinking LED.

and a MSP-EXP432P401R LaunchPad(red board rev. 2.2).

I am using CCS 9.0.1 and TI v18.12.2.LTS compiler.

All other project settings are set to default during import from Resource Explorer.

Please advise how to fix this issue.

Thank you.

  • 0
    TI__Guru 71091 points

    Can you compare with this example?

    /*
    * Use GPIO as DMA callback for processing the RMS calculation. This will be
    * called every 32 measures. In this case we do not want to use the driverLib
    * APIs in FLASH or ROM but keep everything in SRAM
    */
    #if defined(__TI_COMPILER_VERSION__)
    __attribute__((ramfunc))
    #elif defined(__IAR_SYSTEMS_ICC__)
    __ramfunc
    #elif defined(__GNUC__)
    __attribute__((section(".TI.ramfunk")))
    #elif defined(__CC_ARM)
    __attribute__((section(".TI.ramfunk")))
    #endif

    Regards,

    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 60 points

    In provided example only one function is located in SRAM and therefore it works.

    What I found is when I specify __attribute__((ramfunc)) explicitly for every function(except SystemInit) it works.

    I am using this example

    If I compile with flag --ramfunc then the .TI.ramfunc section looks like this:

    .TI.ramfunc 
    * 0 000000e4 000000c0 RUN ADDR = 01000000
    000000e4 00000078 system_msp432p401r.obj (.TI.ramfunc:SystemInit)
    0000015c 00000048 msp432p401x_1.obj (.TI.ramfunc:main)

    When I compile without --ramfunc flag SystemInit is located in .text section and this example is working.

    If I compile without --ramfunc and specify __attribute__((ramfunc)) only for SystemInit function, the program stops to work.

  • 0 in reply to Anton Proskurnin73136
    TI__Guru 71091 points

    The Reset_Handler performs the SystemInit before C initialization.  

    void Reset_Handler(void)
{
    SystemInit();

    /* Jump to the CCS C Initialization Routine. */
    __asm("    .global _c_int00\n"
          "    b.w     _c_int00");
}

    Please also see this discussion:

    e2e.ti.com/.../543562 

    Regards,

    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 60 points

    Can you please try to compile any of the exaples for the board with the --ramfunc flag and tell me the result?

    Or as i've said previosly try to compile with __attribute__(ramfunc) SystemInit() and see the result.

  • 0 in reply to Anton Proskurnin73136
    TI__Guru 71091 points

    I believe this will cause an issue as you have demonstrated.

    In the examples SystemInit() is performed before the C init.  And C init is the mechanism which takes the information in flash marked as ramfunc and moves into SRAM.  If SystemInit() is marked as ramfunc but called before the SRAM is initialized then the memory location may represent an invalid instruction. 

    Please remember that upon power up that the SRAM is not preserved and needs to be reinitialized from non-volatile memory (Flash).  

    Do you need to have everything executed from SRAM?  For the most part the SystemInit() is not needed (, be removed) and you could simply leave the default values and then configure the device after C init.

    Another thing to consider is that a number of the driverLib calls are in ROM.  While I do not believe this is critical, some compilers do not like functions in RAM that call outside of RAM.  In the example I referenced earlier I had almost all of the code in SRAM but with IAR I received compiler warnings about the driverLib calls (we are not supposed to publish code with warnings and this is a very helpful warning) and I had to re-write.

    Regards,
    Chris

**Attention** This is a public forum