• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 641 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.

MSP430FR5994: accessing using FRAM2

Michael McGuire
Prodigy 80 points

Part Number: MSP430FR5994

Hello,

I am trying to utilize the extra memory available on FRAM2.  I am having trouble though.  I use pragma to assign a variable to the memory space I want to use

#pragma DATA_SECTION(accelerometer_X, ".testObjSeg")

_q15 accelerometer_X[SAMPLES];

and I edit the linker to associate the memory location.

.testObjSeg : {} > FRAM

so far, this is ok except for I still run out of memory.  I tried associating the memory to FRAM2 but run into issues.  The first issue being, the debugger doesn't seem to make it past bringing up the board.  The second issue is there are specialized functions for using the extended address's for FRAM2 that I am unfamiliar with.  Is there anyone who can point me to a good starting place learning to use the FRAM2 in the extended address and memory locations ? ? ?

Thank you for your help,

Michael

  • 0
    TI__Mastermind 30386 points

    Hi Michael,

    Please help to check if this document is helpful for you:

    https://www.ti.com/lit/an/slaa628b/slaa628b.pdf

    Thanks!

    Best Regards

    Johnson

  • 0 in reply to Johnson He
    Prodigy 80 points

    Thank you, and this was a good start to more familiarize myself with FRAM and memory protection ( I may need to do more with __low_level__init(void), and I do have the MPU settings disabled at this point ).

    Still, I am thinking there are specialized function for accessing FRAM2 on this device.  For instance, in the linker you can see the beginning of FRAM2 is located at 0x10000.  I beleive this requires specialized functions because the address space is longer than the other sections of memory

    MEMORY
    {
    TINYRAM : origin = 0xA, length = 0x16
    BSL : origin = 0x1000, length = 0x800
    INFOD : origin = 0x1800, length = 0x80
    INFOC : origin = 0x1880, length = 0x80
    INFOB : origin = 0x1900, length = 0x80
    INFOA : origin = 0x1980, length = 0x80
    RAM : origin = 0x1C00, length = 0x1000
    FRAM : origin = 0x4000, length = 0xBF80
    FRAM2 : origin = 0x10000,length = 0x33FF8 /* Boundaries changed to fix CPU47 */
    JTAGSIGNATURE : origin = 0xFF80, length = 0x0004, fill = 0xFFFF
    BSLSIGNATURE : origin = 0xFF84, length = 0x0004, fill = 0xFFFF
    IPESIGNATURE : origin = 0xFF88, length = 0x0008, fill = 0xFFFF
    INT00 : origin = 0xFF90, length = 0x0002
    INT01 : origin = 0xFF92, length = 0x0002
    INT02 : origin = 0xFF94, length = 0x0002
    INT03 : origin = 0xFF96, length = 0x0002

    ......

    I don't suppose you can point me to a minimal coding example, just to initialize, write to, and read from an array I would like to store in this large block of memory?

    Also, I am using CCS.  There might be a setting for using the 20-bit address memory space.

    Regards,

    Michael

  • 0 in reply to Michael McGuire
    TI__Mastermind 30386 points

    Hi Michael,

    I am sorry that I don't understand your issue clearly, could you put the problem you encountered again?

    Thanks！

    Best Regards

    Johnson

  • +1 in reply to Michael McGuire
    Guru 25475 points

    You can of course tell the compiler to use 20 bit addresses but this will cause code size to increase.

    For simple use cases the special functions (void __data20_write_char(unsigned long addr, unsigned char src); for example in GCC) will do the trick. Consult the CCS documentation to see what it provides.

  • 0 in reply to David Schultz
    Prodigy 80 points

    Hi David, 

    Thank you, this resolved my issue.  Here is a snippet of code, storing _q15 samples for later FFT

    #define SAMPLES     1024

    unsigned long int accelerometer_X = 0x10000;

    unsigned long int accelerometer_Y = 0x10800;

    unsigned long int accelerometer_Z = 0x11000;

     

    ……

     

    // Collect readings

    _q15 temp_reading = 0;

    unsigned long address_multiplier = 2;

     

    unsigned long location_X = (accelerometer_X + (counter*address_multiplier));

    unsigned long location_Y = (accelerometer_Y + (counter*address_multiplier));

    unsigned long location_Z = (accelerometer_Z + (counter*address_multiplier));

     

     

    temp_reading = i16_get_X_Axis_accelerometer();

    __data20_write_short( location_X, temp_reading);

     

    temp_reading = i16_get_Y_Axis_accelerometer();

    __data20_write_short( location_Y, temp_reading);

     

    temp_reading = i16_get_Z_Axis_accelerometer();

    __data20_write_short( location_Z, temp_reading);

    There is a similar intrinsic read function as well.

    Best Regards,

    Michael

  • 0 in reply to David Schultz
    Prodigy 80 points

    Hi David,

    Increases in code size can be an issue.  My code would not work setting the compiler to always use 20-bit address size with large_data_model and large_code_model.  Though it is a quick fix changing these values in the CCS project configurations, it broke some aspects of the code.  Using these functions worked well, limiting the 20-bit address accesses to exactly where I needed them.

**Attention** This is a public forum