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/MSP430FR5994: moving .sysmem/.bss to FRAM memory

Part Number: MSP430FR5994

Tool/software: Code Composer Studio

Hello,

I am trying to implement algorithms which are written in MATLAB to work on a MSP430. I use the MATLAB Coder for C code generation. The problem is, that these MATLAB functions' variables take up a lot of space on the uC. In the settings of the coder, I can choose between static or dynamic allocation of variable sized arrays. So, either the .sysmem or the .bss portion of the memory get really big. That leaves me two options for the memory on the MSP430:

1. move the heap (.sysmem) to FRAM2

2. move .bss (and maybe .data) to FRAM2

For option 1, I tried different alterations of the .cmd file, but non of them worked. I think my understanding of that file is not that well to modify it in a correct way.

For option 2, I just put FRAM2 instead of RAM in the .cmd file, but an error occurs:


#17003-D relocation from function "activity_recognition" to symbol "activity_not_empty" overflowed; the 18-bit relocated address 0x25a73 is too large to encode in the 16-bit field (type = 'R_MSP430X_ABS16' (15)

.bss        : {} > FRAM2                  /* Global & static vars              */
.data       : {} > RAM                  /* Global & static vars              */
.TI.noinit  : {} > RAM                  /* For #pragma noinit                */
.stack      : {} > RAM (HIGH)           /* Software system stack             */

I  also changed the data model from restriced to large, but this doesn't do anything.

Can someone provide working code for either or both of the options? I'm also not sure which of them is the better way to do it.

Thanks,

Andrea

 

  • Hello Andrea,

    Don't mess with the command linker file. Move the variables into FRAM memory using the PERSISTENT pragma: www.ti.com/.../slaa628.pdf

    Regards,
    Ryan
  • Hi Ryan,

    thanks for the quick answer, but this is quite impractical for me. The coder generates functions with many varibles each and I would have to move every one of them to FRAM manually. Also, everytime I change something in MATLAB and generate the new code, the files will be overwritten and variable names might be changed, so that I would have to do everything again.

    Greetings,
    Andrea
  • Hi Andrea,

    Relocate .sysmem from inside the READ_WRITE_MEMORY group to below the .text:_isr declaration and allocate it to FRAM2:

    .text:_isr : {} > FRAM /* Code ISRs */
    .sysmem : {} > FRAM2 /* Dynamic memory allocation area */

    There could be an issue with moving global & static variables to large memory areas (>0xFFFF) , you could try moving them to FRAM instead and specify code & constant data only be placed in FRAM2.

    Regards,
    Ryan
  • Hi Andrea,

    One other suggestion is to go beyond MATLAB Coder, and use Embedded Coder. Embedded Coder gives you full control over the generated code, and allows for generation of optimized code. The code that comes out of Embedded Code is as efficient, or more efficient then hand code.

    In addition you can select the main objective for your generated code from these choices: (doc link, login may be required)

    In your case, you probably would want to explore the ROM / RAM efficiency options.

    HTH,

    -Brian

  • Hi Brian,

    Embedded Coder is already installed on my computer, but it only adds a few more options to the Matlab Coder settings. I think to get full configuration possibilities (with the efficiency options), you need to generate code from Matlab Simulink, which I am not doing (I was only given a script with a few algorithms written in the standard Matlab editor). I also couldn't find a support package for MSP430FR5994 or similar devices. If you have more information about generating decent code from Matlab for the MSP430x, please let me know.

    Greetings,

    Andrea

  • Hi Ryan,

    moving .sysmem to FRAM2 causes the program to get stuck inside a loop in the malloc function:

    /*-----------------------------------------------------------------------*/
        /* Find the first block large enough to hold the requested allocation    */
        /*-----------------------------------------------------------------------*/
        while (current != LIMIT && -current->packet_size < allocsize)
        {
        prev = current;
        current = current->next_free;
        }

    When I use the debugger, the program behaves quite strange, the second condition of the while loop is false, but the loop is not exited. The arrays I'm trying to allocate might be too large, so I'm back to trying to move .bss to FRAM2.

    I have tried several other different things with the memory allocation , which all lead to further, more complex errors. So in the end it all comes down to the error I described in my original post:

    Andrea Dorn said:


    #17003-D relocation from function "activity_recognition" to symbol "activity_not_empty" overflowed; the 18-bit relocated address 0x25a73 is too large to encode in the 16-bit field (type = 'R_MSP430X_ABS16' (15)

    .bss        : {} > FRAM2                  /* Global & static vars              */
    .data       : {} > RAM                  /* Global & static vars              */
    .TI.noinit  : {} > RAM                  /* For #pragma noinit                */
    .stack      : {} > RAM (HIGH)           /* Software system stack             */

    I  also changed the data model from restriced to large, but this doesn't do anything.

    which occurs because I put the .bss in FRAM2, which starts at adress 0x10000. Can I somehow change the settings to overcome this error? I found a similar post https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/313159

    Where setting a flag in the GNU Linker->Miscellaneous options solved the issue. But I can't find the 'Other flags' section in my project settings; I am using MSP430 Linker.

    And here my properties window:

    I think this is the easiest way for me right now, to find a way to use the upper part of memory for my variables and data. If this is possible, that is.

    Greetings,

    Andrea

  • Hey Andrea,

    Have you tried changing the --data_model option in Project Properties -> CCS Build -> MSP430 Compiler -> Processor Options from "restricted" to "large"?

    Regards,
    Ryan
  • Ryan Brown1 said:


    Have you tried changing the --data_model option in Project Properties -> CCS Build -> MSP430 Compiler -> Processor Options from "restricted" to "large"?

    Yes, but the errors (actually, they are just marked as warnings) concerning the upper addresses still come up.

    Andrea

**Attention** This is a public forum