• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 2882 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.

CCS/MSP430FR5994: Variable array in FRAM space

Laszlo Madarasz
Intellectual 600 points

Part Number: MSP430FR5994
Other Parts Discussed in Thread: AFE4404

Tool/software: Code Composer Studio

I am working with an MSP430FR5994 microcontroller. Development platform/environment used: CCS 6.2.

For Collecting an analyzing data, I need to use large size block of data, which cannot fit in the RAM memory. So I would like to move them to FRAM memory.
I had been reviewed in detail the corresponding documentation: slaa628, slau132q 5.11.20 and slaa685 plus all forum entries I coupd find regarding to this issue. 

FRAM_VARIABLES
{
  *(*:greenArray)
} > FRAM

In main.c:

long greenArray [256] = {0};


Without a accessing the block of data, the program compile, load and run without a glitch. But as soon as I insert this code to the initialization section, the program fail to run though properly compiled and loaded.

for (j=0; j<256; j++)
{
  greenArray[j]=0;
}


Could you help me please what should be done to make this solution working?

The #pragma NOINIT solution unfortunately has the same result.

  • 0
    TI__Intellectual 1370 points

    Hi Laszlo,

    Have you taken a look at the msp430fr599x_framwrite.c example? It sounds like that might be what you're looking for.

    Your initialization code would look something like this:

    #if defined(__TI_COMPILER_VERSION__)
#pragma PERSISTENT(greenArray)
long greenArray[256] = {0};
#elif defined(__IAR_SYSTEMS_ICC__)
__persistent long greenArray[256] = {0};
#elif defined(__GNUC__)
long __attribute__((persistent)) greenArray[256] = {0};
#else
#error Compiler not supported!
#endif

    The array will be initialized to zeros the first time the code is loaded onto the MCU, but then the values written to the array will be persistent in FRAM even if the MCU resets until the program is reloaded onto the MCU.

    Regards,

    Ryan

  • 0 in reply to Ryan Meredith
    Intellectual 600 points

    Hi Ryan,

    Thank you for the initialization code, and the example. The example code successfully run perfectly.

    I was trying to adopt the solution to my own code, but there is some problem. The AFE4404 sensor cause an interruption at every 10ms. I had added a LED toggle function to the interruption routine to get confirmation that thats the one running.

    During development, we are monitoring all results measured through UART, which does not work. There is an obvious correlation between the block data created in FRAM and the problem with the UART. The processor clock is running on 8Mhz, which based on my knowledge a perfectly working speed for writing the FRAM.

    For me, it seems that it get stuck in a never ending loop at:

    for(j=0; j<256; j++)
{
  greenArray[j]=0;
}

    but on the ither hands, the interruption handling works perfectly.

    Many thanks for any idea and help,

    Laszlo

  • 0 in reply to Laszlo Madarasz
    TI__Intellectual 1370 points
    Hi Laszlo,

    I'm glad the initialization code worked for you! Where is the for loop located in your program? It seems strange that the code would be hanging in the for loop unless your variable j is being modified in an interrupt somewhere or interrupts are occurring frequently enough that the for loop is executing very slowly. You might want to try adding a watch expression for j in the CCS debugger and writing distinct values to greenArray for testing to see if any data is being written to it during code execution.

    What are you using UART to communicate to and what are the register settings you are using to initialize it? If the MCU is receiving data through UART, are you able to set a breakpoint in the UART to see if data is being received?

    Regards,
    Ryan
  • 0 in reply to Ryan Meredith
    Intellectual 600 points

    Dear Ryan,

    I had found the error, the "j" variable type was unsigned char.
    Since it can take value between 0-255, therefore the j<256 is always true...
    I had modified its type to unsigned int, and now it works perfectly.
    I am still validating the data block content in FRAM, but it seems to work perfectly.

    Thank you for your help! the code sample you gave was very usefull!

**Attention** This is a public forum