• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 80 subscribers
  • Views 2662 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Why Flash/FRAM Memory Partitioned?

Rodney Wong
Intellectual 650 points
Other Parts Discussed in Thread: SYSBIOS, MSP430FR5969

I am new to TI embedded devices. But I had worked with other embedded devices (Motorola, AVR, and PIC).

I was trying to trying to compile some code with Code Composer Studio for a MSP430FR5969. However, CCS couldn't compile because 'program  will not fit into available memory'. 

I tried to the code with a different version of MSP430, F5529. And CCS compiled the code without any problems.

I found was that the FR5969 has its code memory partitioned in to 48kB and 16kB. Also the F5529 has its code memoty partitioned in to 48kB and 83kB. What was the limiting factor was the partitioning. The code going into the second partition for the F5529 was 19kB. This is what couldn't fit into the F5969's second partition (16kB).

Why is the flash/FRAM memory partitioned? Is this because of hardware setup or a CCS configuration?

Your help would be much appreciated.

  • 0
    Guru 27285 points

    Rodney Wong said:
    I am new to TI embedded devices. But I had worked with other embedded devices (Motorola, AVR, and PIC).

     Hi Rodney, with Motorola you intend Freescale or old ancient processor? I got nostalgic on that old name.

    Rodney Wong said:
    was trying to trying to compile some code with Code Composer Studio for a MSP430FR5969. However, CCS couldn't compile because 'program  will not fit into available memory'. 

     FR part are special processor with FRAM, inthese processor there where no ram at all so a protection mechanism is in place to protect code area from where ordinary data flash and ram too normally reside.

     If you started with an huge program then small model has to be changed from default.

     F5529 is an X processor, it extend over 64K Kb so register are 20 bit wide, again RAM is partitioned by a register and you need enable disable due to power consumption.

     These processor are flexible and powerful but you started with the top series and some topic need be understood about large program.

     From your IDE picture it seems also code is fit to ram than flash, is this coming from FRAM part setting?

  • 0 in reply to Roberto Romano
    Intellectual 650 points

    Roberto -

    Thanks for the quick update.

    The pix with the FRAM is from the FR5969. The pix with the Flash is from the F5529.

    I don't think the partitioning is the problem. I moved the memory around and the compilation still didn't work. (I tried moving around memory on another program, and the program compiled fine.)

    Now, I am thinking the FR5969 cannot handle SYS/BIOS. BTW this program that cannot compile is straight from the templates and examples. It is the SYS/BIOS->TI Target Examples->Minimal. As you can see from the below pix, the failed allocation from the 'program  will not fit into available memory' was mainly due to sysbios stuff.

    Are there anyways to fix the failed allocations?

  • 0 in reply to Rodney Wong
    Guru 23000 points
    Memory Sections are partitioned by default as thy appear in the device.

    In the “Linker Command File” (<device>.cmd), placed in the Root of your project, is defined which piece of code has to be placed in which Memory Section. You can create more sections or substitute all sections into one.
  • 0 in reply to Rodney Wong
    Guru 27285 points

     

    Rodney Wong said:
    Are there anyways to fix the failed allocations?

     Yes, as Leo pointed you section on linker file need be adjusted so if you fix yourself no problem otherwise please post cmd file or zip all project directory and post that so we can see what is wrong.

    If this is an example program we can also ask to be revised, new version of CCS and MSPWare I read is buggy.

  • 0 in reply to Roberto Romano
    Guru 16361 points

    Roberto Romano said:
    FR part are special processor with FRAM, inthese processor there where no ram at all so a protection mechanism is in place to protect code area from where ordinary data flash and ram too normally reside.

    FR parts are available that have SRAM as well as flash. For example, MSP430FR5969 has 2KB of SRAM and 64KB of FRAM.

    Rodney, as well as posting your linker .cmd file it would be helpful to post the .map file produced by the linker in the build target output directory. From that it should be possible to tell whether things can be rearranged to fit on FR5969.

  • 0 in reply to Robert Cowsill
    Guru 27285 points

    Robert Cowsill said:

    FR parts are available that have SRAM as well as flash. For example, MSP430FR5969 has 2KB of SRAM and 64KB of FRAM.

     The USB buffer  ram can also be used as program ram, right. I suppose trouble come from code allocation, map file with linker can troubleshoot in a single shoot.

  • 0 in reply to Roberto Romano
    Guru 16361 points

    Roberto Romano said:

     The USB buffer  ram can also be used as program ram, right.

    That's correct on MSP430F5 parts with the USB peripheral, but there currently aren't any FRAM parts with USB as far as I know.
  • 0 in reply to Robert Cowsill
    Guru 27285 points

    Robert Cowsill said:
    That's correct on MSP430F5 parts with the USB peripheral, but there currently aren't any FRAM parts with USB as far as I know.

     Hi Robert, thank a lot for advice, it is time to get an FR launchpad and learn in details, I am using more F series for motor control and industrial application, I never felt the need of extreme low power, I just learned register on both series are very similar so I give more care.

     Next buy from estore with MSP432 an FR can be a good pair.

  • 0 in reply to Rodney Wong
    TI__Guru 70426 points

    Hi Rodney,

    The reason that there is an FRAM and FRAM2 and FLASH and FLASH2 on these parts instead of just one continuous block, is somewhat historical - it is to make the memory fit with the memory maps of smaller MSP430s. The oldest MSP430 devices did not have large enough memory to need more than 16-bit addresses. The memory map was defined having the interrupt vector table at the very end of the 16-bit address range around 0xFF80 and ending with the reset vector in 0xFFFE-0xFFFF. When devices were created that needed 20-bit addresses to be able to encompass unique addresses for all RAM, Peripherals, and FLASH, the additional flash space was then added in a section FLASH2 after the interrupt vector table, starting at 0x10000. The goal was for backwards compatibility I believe and to not have to fundamentally alter the existing design having the vector table just below 0xFFFF.

    So that's why you've got 2 areas of FLASH/FRAM on these parts - it's to make the memory map work out with the interrupt vectors in the same place - the vector table is dividing/sitting between these two areas. Interesting side-note - because of this if you have a small program and can fit it in lower FLASH/FRAM only, you can then use only 16-bit instructions and no 20-bit instructions making your code more efficient (this is why there are different data and memory model options in the compiler) .

    For your TI-RTOS questions/difficulties - you may want to post something in the TI-RTOS forum if you have not already: e2e.ti.com/.../tirtos

    Regards,
    Katie

  • 0 in reply to Leo Bosch
    Intellectual 650 points

    I posted a reply on the TI-RTOS forum.

    Looking forward for your help.

  • 0 in reply to Robert Cowsill
    Guru 227245 points
    By default, variables are placed in RAM. Which is only 2k. However, FRAM can also be used for storing variables. But that's not done by default.

    Personally, I think that on FRAM devices, RAM should be reserved for the stack (to circumvent speed penalties for CPU speeds >8MHz) and all global (except for the most-often accessed) variables should be put into FRAM.
    However, splitting FRAM between protected code space and unprotected data space (and maybe even protected data space for config data) isn't a simple job for a linker. SO the linker keeps its placements simple: constant to FRAM, dynamic to SRAM.
    If you want it differently, it is up to you to tweak the linker file for more sections, and maybe tell the compiler which section to use for what.

    Getting the best out of a microcontroller is no simple point&click job. It's engineering work. :)
  • 0 in reply to Jens-Michael Gross
    TI__Guru 70426 points
    Jens-Michael,

    Placing variables in FRAM and partitioning for the MPU is much easier now and doesn't usually involve linker file modification anymore. If you use the MPU tool built into CCS project properties, you can enable the MPU and select to let the linker choose the boundaries for you. If you want to place variables in FRAM (not just constants), you then simply use the PERSISTENT pragma and they'll automatically be placed in the read/write section of FRAM by the linker. The linker + MPU tool will see what size the read/write section must be (that also meets MPU granularity) and make the segment the needed size, and enable the appropriate MPU protections (in that case allowing read/write). It's very cool and much smoother than the way you had to do this a year or so ago.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Guru 227245 points
    Good to hear that there has been a significant improvement in this area lately.
    I didn't follow the FR parts much after the initial launch, and back then it was quite complicated to make use of the new possibilities of the FRAM.

**Attention** This is a public forum