MSP430FR5969: Access MSP430 memory above 0x10000 + Energia Imported Sketches (which implies use of unsupported MSPGCC 4.6.3)

Hi Mario,

To best assist you, I will need some context about your original question.

Can you please provide the link to the original post (I do not see it in your post history) or a short description of your original issue and resolution.

Thanks,

-Chris

Dear Chris, thank you so much for your assistance.

The original post about this subject is not mine, I don't know what happened, but I have clicked "Ask a related question" over John Wygonski's post named "MSP430FR5969: Using FRAM above 0x10000 with MSPGCC 4.6.3" but the system did not link my question to that post. Anyway, it is the very same problem, so if you could take a look at that post (link = e2e.ti.com/.../613829) maybe it will clarify better the whole question.

Hope to hear from you soon,
Mario

Energia currently does not support upper memory due to the limitations in mspgcc. The goal was to release an msp430-core with msp430-elf-gcc a while back. Unfortunately at that time, the binary size produces by msp430-elf-gcc was too large and would not have fitted some of the most basic sketch in some of the msp430's.

With that said, there is an upcoming release of msp430-elf-gcc that does get the size down to where it is usable. If you would like to give this a try then please send me an e-mail at make@energia.nu with the subject msp430-elf-gcc and I will send out the instructions.

Robert

Dear Robert, thank you very much!

I am emailing you right away.

Will consider this thread as solved as soon as this test works fine.

Mario

The old thread you refer to was about accessing data in the upper memory area. You can write functions to do that without much effort.

If the problem is code size then the upper memory will be of little help. I checked using a current version of gcc and switching to -mlarge to get 20 bit pointers resulted in a 20% increase in code size. For a ~50K block of code that increase would use up almost all of the extra 16K of memory. It would be nice if linker relaxation were available to reduce pointer sizes where possible but the MSP430 isn't on the list of targets that support it.

I am currently trying Robert's solution, will give a feedback to this thread in a couple of days even if I cannot make it work. It is quite a job because I am having to migrate a lot of internal libs and they are not compiling by just copying it, some directories have changed on the core. Hope to have better info soon.

David, thank you for your answer! Actually my goal is to make a customized bootstrap, but my main program is about 44 ~ 46kB. I don't have the whole strategy formed on my mind yet because I am stuck on this memory region control problem, but I was willing to use the higher memory to store some methods currently on low memory, giving me room at $4400h to put the custom bootstrap and segment other things in code throughout the memory, so I will be able to make partial upgrades only in specific memory regions (i.e., a region for main program, a region for libraries, ...) and hoping that the transmission goes without errors (no memory available for temporary upload to another region, check CRC and substitute if OK). I am having now this DWARF error as on my last reply. Please share your thoughts if you have any clue about what may be causing this.

Thank you,

Mario