MSP430 use FRAM above 0x10000

[wygonski 0]

I would like to locate code (or data) in upper FRAM using something like:

void __attribute__((section("REGION_FAR_TEXT"))) myFunction(void);

This should be possible because Energia for MSP430 memory.x files have a line

REGION_ALIAS("REGION_FAR_TEXT", far_rom);

and far_rom is declared as:

  far_rom          : ORIGIN = 0x00010000, LENGTH = 0x00004000 /* END=0x00014000, size 16K */

but this was not working back in Energia E20.

Is this working now in Energia E23?

[StefanSch 10]

The current compiler in Energia does not support instructions addressing the upper memory space - so it will not work.

If you like, you can use a beta implementation using the latest released GCC compiler for the MSP430 and test it on this project.

Just add this path in the file | Preferences | Additional Board manager section:

http://s3.amazonaws.com/energiaUS/packages/package_msp430_elf_GCC_index.json

open the board manager and install the latest version of the Energia MSP430 boards (elf-GCC)

 

Any feedback on this is welcome!

[Rei Vilo 695]

Have a look at this branch of the MSP430 with the Build instructions.

It works great and allow to use the whole memory. Very useful with the 256 KB MSP430FR5994.

[wygonski 0]

Thank you both StefanSch and Rei Vilo for your helpful responses.  I will go back to our dev group to discuss the options you presented.   

If I understand correctly, both your suggestions involve  modifying or rebuilding the Energia tools.     Our group has a few developers working on product code which started in Energia and grew over the years, and and it's not clear that we have the expertise to take that on in order to solve our memory space problem with our MSP430 codebase.   Do either of these two options hold the possibility of being merged into the Energia main trunk at some point down the road?

 If I am not understanding correctly please let me know.  In any event, thank you for your quick responses and we may take one of the options you suggested.

[StefanSch 10]

The two proposals are basically the same, where mine is just the already  compiled and packed solution of the repository mentioned in the other post.

The elf compiler tool chain has been tested for quite a while but it is still beta phase.
There are plans to officially release the elf compiler as well but not a fixed time schedule.
The good thing:
- both tool chains are compatible where the elf compiler does support newer C standard and also the upper memory regions.
- you can use both in parallel you just need to select in the board manager the board and the compiler tool chain.
But:
- the elf compiler might generate some more code due to the support of the upper memory with the extended addressing required for that.

And any feedback is welcome....

[wygonski 0]

Hi, thanks very much for the clarification and I am enthusiastic to try out your suggestion.   I started by downloading Energia 1.8.11E23 from the Energia site, and then I added the path to the additional boards managet URL in Preferences.  

However I am having difficulty installing the latest version of the Energia MSP430 boards (elf-GCC).   It hangs while installing after the download and     And same hanging behavior installing v1.0.7 of Energia MSP430 boards.  

Is there a different place I sould be asking for help with this one?  (Google did not turn up anything useful.)

[StefanSch 10]

Sorry, do see this problem the first time.

Can this be access rights problem?

How have you have you waited to complete?

Which OS you are using?

~ Stefan

[wygonski 0]

After restarting Win10 and reinstalled Energia again.   Installed ENergiaMSP430 boards (elf-GCC) and waited patiently (>30 minutes!) even though the install appeared to hang as before.   Finally shows installed:

Moving on to try out the use of upper FRAM with MSP430FR5969.  Started with a project that utilized around 94% (approx number is 47300 bytes) of the available 48k in FRAM.  Added 

__attribute__((section("REGION_FAR_TEXT")))

to a few function definitions and the build output shows:

Sketch uses 44912 bytes (93%) of program storage space. Maximum is 48128 bytes.

So is this good sign, program memory size is reduced?  And where is the code relocated to?   I assume to "REGION_FAR_TEXT" mapped to memory region "far_rom" at 0x010000 as declared in the memory.x file.  Also, Maximum size is not correct (continues to report 48128 bytes) in that it is not taking into account upper FRAM that should be available.

However then I added  the section attribute to another function declaration, and the build failed, with the error message indicating that the linker is trying to locate the function in memory region "ram".   So this is a bit puzzling to me:

c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-gcc/4.6.6/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe: C:\Users\johnw\AppData\Local\Temp\arduino_build_27531/Master_Firmware_ZFM_Gen1_5_V1_8_08-08-2018.ino.elf section `REGION_FAR_TEXT' will not fit in region `ram'

c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-gcc/4.6.6/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe: region `ram' overflowed by 348 bytes

I looked in my %appdata% path and I do see the msp430-elf-gcc folder in addition to the msp430-gcc folder in packages/energia/tools.   In preferences.txt I do have

boardsmanager.additional.urls=http://s3.amazonaws.com/energiaUS/packages/package_msp430_elf_GCC_index.json

So this build output does not look right, can you advise?

 

[StefanSch 10]

The elf gcc compiler automatically uses the full memory space (upper and lower).
If you need to place certain functions into upper or lower memory you should use

__attribute__((section(".lower.text")))

__attribute__((section(".upper.text")))

The calculation of the used memory needs some update, esp. the available memory is not showing the full (upper and lower memory)

What happened at your side: not sure but i assume with the __attribute__ you have used the code did went into the RAM

[wygonski 0]

Thanks for the reply, I made the change as you pointed out.    I also needed to change my board selection to MSP-EXP430FR5969LP in Energia MSP430 boards (elf-gcc) instead of the default boards package.

Now I am seeing this build error:

c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-elf-gcc/8.3.0.16/bin/../lib/gcc/msp430-elf/8.3.0/../../../../msp430-elf/bin/ld.exe: C:\Users\johnw\AppData\Local\Temp\arduino_build_821791/Master_Firmware_ZFM_Gen1_5_V1_8_08-08-2018.ino.elf section `.upper.text' will not fit in region `HIFRAM'

c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-elf-gcc/8.3.0.16/bin/../lib/gcc/msp430-elf/8.3.0/../../../../msp430-elf/bin/ld.exe: region `HIFRAM' overflowed by 24605 bytes

I have removed all the section directives in my source code but still this error persists.   The size of the original code (small memory model) is around 47 kBytes.  It is not clear to me why upper FRAM is overflowing by over 24 kB, isn't lower FRAM used first?

Thanks for your help,

John

[StefanSch 10]

It looks like that the compiler setting for the large memory model is not set correct.

can you open the platform.txt file in

c:/users/johnw/appdata/local/energia15/packages/energia/hardware/msp430elf/2.0.7/platform.txt

and change line 21 from

compiler.mlarge_flag=-mlarge -mcode-region=upper

to

compiler.mlarge_flag=-mlarge -mcode-region=either

 

[wygonski 0]

Thank you, that suggestion worked and now there are no build errors.

I compiled a sketch without any section directives and the build output message is:

Sketch uses 47865 bytes (99%) of program storage space. Maximum is 48128 bytes.
Global variables use 1744 bytes (85%) of dynamic memory, leaving 304 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.

Then I added section directives to place a few functions in ".upper.text" and the build output message did not change, which likely reflects your earlier comment that mem size computations are off.

I examined the .hex file records for the two cases and I found that the .hex file after adding the section directives contains an extended segment address record:

:020000021000EC

 which indicates that subsequent data records in the file are located at offset 0x1000 * 16 = 0x10000.    So I believe this demonstrates that those functions are located in .upper.text as desired.

Thank you very much for your time and expertise to get this working for me!   A few followup questions:

1.  Is there a way to instruct the gss-elf compiler in Energia to produce a map file?  

2.  I would like to locate some large initialized data arrays in upper FRAM, and I used a section directive ".upper.data" to achieve this.    However, after examining the .hex file the array did not get located at 0x10000 as desired.    I examined the linker control file for the part I'm using and I saw that the named section ".upper.data" gets mapped to "> HIFRAM AT> ROM" which means the load address is at 0x4000, not at 0x10000 as desired.    I note that in the same linker control file, the named section ".upper.text" gets mapped to "> HIFRAM" so the load address is 0x10000 as prevously demonstrated.  Is this the intended behavior?   

Thank you,

John   

 

[Rei Vilo 695]

You could try editing platform.txt again and changing

compiler.c.elf.extra_flags="-L{runtime.tools.msp430-elf-gcc.path}/msp430-gcc-support-files/include"

for

compiler.c.elf.extra_flags="-L{runtime.tools.msp430-elf-gcc.path}/msp430-gcc-support-files/include"
 -Wl,--cref -Wl,--print-map

 

[StefanSch 10]

The attribute you have used does work, you just do not see this in the memory report as the report summary did not contain section of upper and lower data memory.

When checking the map file (see above) you should see the right placement.

[wygonski 0]

Hi, thanks for your comments.  Just to elaborate a bit on using ".upper.data"

Using the ".upper.data" section directive on an array:

ADI_REG_TYPE  __attribute__((section(".upper.data")))  Param_Data_IC_1[PARAM_SIZE_IC_1] = {
0xFF, 0xEE, 0xEE, 0xDD, 

the resulting .hex file has record
:065E34000100FFEEEEDDAF
showing the load address of the array at 0x5E36 in lower FRAM

I believe the explanation is in the linker control file, where the named section ".upper.data" gets mapped to "> HIFRAM AT> ROM".

Then I changed the declaration to use ".upper.rodata", after seeing in the linker control file that the named section ".upper.rodata" gets mapped to "> HIFRAM"

ADI_REG_TYPE  __attribute__((section(".upper.rodata")))  Param_Data_IC_1[PARAM_SIZE_IC_1] = {
0xFF, 0xEE, 0xEE, 0xDD, 

and the resulting .hex file has records
:020000021000EC
:04000000FFEEEEDD44
showing the load address of the array at 0x10000 in upper FRAM.

So a minor point, just that the ".upper.data" section directive did not behave as I thought it should, and of course the linker followed the attributes in the control file.