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

How to integrate FRAM and FRAM2 memory spaces?

Jason Jones6
Prodigy 50 points
Other Parts Discussed in Thread: MSP430FR5989

Greetings -

I am working with the MSP430FR5989 which has a large FRAM memory which I am using for data storage.  My final application will likely have two large buffers which will take most of the FRAM available.  I would like to remove the distinction between FRAM and FRAM2 in the simplest way possible.

I have modified the linker file to add ".TI.noinit : {}" to the READ_WRITE_MEMORY group and I have modified the line that specifies that no-init memory goes to FRAM instead of RAM and this is working just fine.  Having said that, I am not looking to write an entire linker file anew from this project.  Ideally, there would be a linker checkbox or something of that sort that could insert the appropriate linker file commands.

From what I have gathered, the interrupt vectors are at the upper memory of the 16-bit boundary, resulting in the splitting of the memory that I am observing.  I haven't found anything that allows alternate interrupt vectors to be defined at different memory locations, so it may be that this 'feature' is part of the silicon.

Thanks,

J

  • 0
    TI__Guru* 78191 points

    Hi Jason,

    Jason Jones6 said:
    From what I have gathered, the interrupt vectors are at the upper memory of the 16-bit boundary, resulting in the splitting of the memory that I am observing.  I haven't found anything that allows alternate interrupt vectors to be defined at different memory locations, so it may be that this 'feature' is part of the silicon.

    Unfortunately you cannot use the interrupt vector table area leading up to 0xFFFF for something else - these addresses will always be jumped to by the hardware when the corresponding interrupt occurs - it's tied in with the hardware. You can tell that in turn to point to another address with some proxy vector table containing the real ISR location, but the actual interrupt vector table is always where it's going to go first and so you can't use this area for storing data. I believe the reason this is at these addresses is partly historical reasons because older MSP devices didn't have any memory past 0xFFFF and actually didn't even have an instruction set that supported 20-bit addresses - the 20-bit addresses were added later on newer devices with newer MSP cores where we wanted to have more memory space. But for backwards compatibility the vector table has not moved.

    So what you end up with on this part is that you have FRAM and FRAM2, two separate sections. How large are each of the data buffers that you need to store? Maybe we can help you figure out how best to set this up for your application.

    In addition, have you tried leaving the linker file alone entirely (use the default one) but instead simply using something like #pragma PERSISTENT (myBuffer) when declaring the buffers, and allowing the linker to then place them wherever in FRAM it thinks they'll fit? (see http://www.ti.com/lit/pdf/slau132 and www.ti.com/lit/pdf/slaa628 for more information about the PERSISTENT pragma and FRAM) Though if your buffers are large enough I could see that it may give an error - one of them might not fit simply and require some handling in the code to deal with it.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 50 points

    Katie -

    Thank you for taking the time to explain that this is an unalterable part of the hardware.  That helps me to architect the software for my application.

    I am still working on application code (and the size never seems to go down), but once my application code is finished, I plan to use >90% of the remaining memory as data buffer.  This is the sole reason that we chose this processor.

    Our application takes data every ~20ms and saves a data point.  Once the buffer is full, the processor wakes up and transmits the collected data.  The less frequent the transmissions, the better.  We had planned on using two data buffers, one filling while the other buffer is transmitting and then inactive.  In light of this architectural constrain on the uC, we will probably segment the remaining FRAM memory into smaller buffers that can more easily fit into the segmented memory.  This is a complication, but not a deal breaker.

    I will look at implementing #pragma PERSISTENT().  When I tried this originally, the compiler complained that I wasn't explicitly initializing the variables and I didn't want them initialized.  The #pragma NOINIT() worked well with the slight linker modification.

    Thanks again,

    Jason

  • 0 in reply to Jason Jones6
    TI__Guru* 78191 points
    Hi Jason,

    Sounds like you have a good plan. Let us know if you run into any roadblocks along the way so we can help! :-)

    -Katie

**Attention** This is a public forum