MSP430FR5994: CTPL: A movx.w command overwrites more than 16 bytes of memory

Peter,

Thanks.

The library in use is large. The .text section does not fit in ROM. So I set -mcode-region=either to fit the code in ROM. I notice abnormal behaviour in CTPL when I use -mcode-region=either. How can I ensure that the library and CTPL fit in ROM without -mcode-region?

Peter,

The .text section of my compiled software is larger than the available ROM. The linker description file places .text section(almost 50,000 bytes) in ROM ( 49024 bytes).

I changed the option for -mcode-region=either in the Makefile to fit the .text section.

If I use either option, I notice abnormal behavior in CTPL. If I do not use either option, my code does not fit in the available ROM. 

Is there a way to fit the code(.text) in the available memory?

A snippet from the linker description file:

 ROM (rx)         : ORIGIN = 0x4000, LENGTH = 0xBF80 /* END=0xFF7F, size 49024 */
.text:{

...................

} >ROM

Peter,

Yes, MSP430FR5994 has 256KB of memory, but it is not a contiguous memory location to place code. It is divided into two sections by the interrupt vectors and signatures at 0xFF80 - 0xFFFF.
First section at 0x4000-0xFF7F (which is called ROM in msp430fr5995.ld) (lower FRAM)
Second section at 0x10000 - 0x43FFF (which is called HIFRAM in msp430fr5994.ld) (upper FRAM)
I am referring to the lower FRAM, which is addressed by 16-bit addressing as ROM, and the upper FRAM, which is addressed by 20-bit addressing as HIFRAM, based on the language used in the linker description file.

I tried two techniques to fit code in the available FRAM:
1. -mcode-region flags will help place in the upper/lower memory. I used both either and upper option in the Makefile. My code fit in the code memory, but I notice abnormal behavior when I run it.
2. Manually placed the .text section in HIFRAM (instead of ROM) by modifying the linker description file" .text  : {} > HIFRAM". Again I noticed abnormal behavior. 

Some of the abnormal behaviors I notice are: memory overwrite, device crash at start-up

 I am either not able to fit my software in code memory, or if it does fit, CTPL does not execute correctly.

Any idea on what is going wrong?

I am using msp430-elf-gcc and I use a Makefile to configure the settings.

Archie S said:

I am using msp430-elf-gcc and I use a Makefile to configure the settings.

Have you added a "-mlarge" to the compiler options so that gcc will use 20 bit pointers and addresses?

Peter,

Thanks. The software library I need for my code is designed for the GCC compiler.

I have never needed the additional upper memory area for anything but I might someday so I tried a few things.

I took a small assembly source file and added enough additional data to it to overflow lower memory:

    .section .text.tester,"ax",@progbits
tester:    .ds.b    8000
    .section .text.tester1,"ax",@progbits
tester1:    .ds.b    8000
    .section .text.tester2,"ax",@progbits
tester2:    .ds.b    8000
    .section .text.tester3,"ax",@progbits
tester3:    .ds.b    8000
    .section .text.tester4,"ax",@progbits
tester4:    .ds.b    8000
    .section .upper.text.tester5,"ax",@progbits
tester5:    .ds.b    8000


The documentation (slau646) implies that the linker will place data and code into lower or upper sections as it sees fit. But I found that it would not place my data into the upper text section without including ".upper" in the section name. Without that, the .text.tester5 section overlapped the interrupt vectors.

Another problem is that the default for gcc is to put all code into the .text section so that ld never has a chance to split the code apart. For that you need to include "-ffunction-sections" on the gcc command line so that it places every function in its own section. (Note also that the gc-sections flag lets ld delete unreferenced sections. Which only works if functions are in separate sections.)

Google turned up a conversation from 2014 on this topic and that indicated that patches were in the pipeline that would let ld automatically distribute code between upper and lower memory. If that ever happened it would be nice if slau646 documented how to enable it.

e2e.ti.com/.../369708

Hi Archie,

Unfortunately, this is hard to debug without a test case I can run myself. Is there any way you can provide a reduced test case?

What version of msp430-elf-gcc are you using?

When you say that the movx.w instruction overwrites 337 bytes of memory, did you observe that precisely when stepping over the instruction? i.e. before the instruction, this 337 bytes of memory has a certain value, and when you step over the instruction, the 337 bytes has changed?

What is the instruction trying to do? i.e what is at address 0x0a596 (the source) and &0x1018a (the destination).

Where is this 337 bytes of memory located in relation to the source and destination?

Regards

Hi David,

The linker will only "shuffle" code and data sections between upper and lower memory if:

• -mcode-region=either and/or -mdata-region=either is passed to GCC
• the lower memory region is overflowing

So I would expect your testcase to build successfully and put some sections in the upper memory region to prevent the lower region from overflowing, if you pass -mcode-region=either.

The clarity of the documentation on this area has been improved in the next version of the MSP430-GCC User Guide (slau646).

David Schultz36 said:

Another problem is that the default for gcc is to put all code into the .text section so that ld never has a chance to split the code apart. For that you need to include "-ffunction-sections" on the gcc command line so that it places every function in its own section. (Note also that the gc-sections flag lets ld delete unreferenced sections. Which only works if functions are in separate sections.)

Unfortunately, -ffunction-sections and -fdata-sections have negative side effects in some situations (e.g. disabling optimizations, increasing code size), which means that we cannot enable these options by default.

Regards,

Thank you for the suggestions.

David, I have tried the code splitting techniques and I end up with the same problems.

Peter,  I look forward to some way to solve this problem.

Jozef, I use msp430-gcc version 7.3.1.
I stepped into each instruction in the assembly code and observe this memory overwrite when I stepped over the particular movx.a instruction.
The source (0x0a596) is a value which is used to set the ctpl-valid flag which is at address 0x1018a.
 Until this movx.a, the memory location form 0x10188 is filled with correct data. As soon as this movx.a is executed, the memory from 0x10188, upto 337 bytes, is overwritten with some data (I cannot identify what is the source of the data which is overwritten into the memory).
I observe the memory overwrite around the destination address, from 0x10188 to 0x102d9.

How do I share a reduced test case?

From my experiments, I think the problem lies with compiling CTPL with mcode-region=either option.

Archie,

Thanks for providing further information.

I would recommend to always try to use the latest MSP430-GCC, which at the moment is 7.3.2. Each new release has bug fixes and new features, and they could affect your program.

You can get the latest version in CCS, or a direct download here: http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html

How do I share a reduced test case?

If you can zip up a directory with the Makefile and source code, you should be able to directly attach it when you make a post in this thread.

Thanks

Hi Peter,

I am working on sharing the project here. I made changes to the project, I am trying to reproduce the same error. I will share them by tomorrow.