MSP430FR5994: IP Encapsulation Manual Placement?

Hello Kenan,

It seems that this is one function of IAR compiler. I recommend you contact with IAR directly, which is more fast. You can try to contact with this email: support.cn@iar.com

This is their technical support.

BR,

Janz Bai

Hello Janz,

The screenshot was taken from CCS v12.8.1; this is not an IAR-specific feature. Additionally, if you review the document below, you’ll find extensive explanations of this functionality—although it does not cover manual address placement.

https://www.ti.com/lit/an/slaa685/slaa685.pdf

I’ve come across partial information in several different documents, but I’m confident that this should be possible to achieve in CCS.

Best Regards,

Hello Kenan,

Sorry for that I misunderstand your meaning. Let me send this post to our SDTO team who is responsible for IDE and compiler, to ask for their comments.

BR,

Janz Bai

Kenan - I assume you are looking to do this manually in your linker command file. This is something the device experts can help with. I will bring this thread to their attention.

Thanks

ki

Hello Kenan,

I think this app note maybe can help you, you can look into this:

MSP Code Protection Features

Best Regards, 

Janz Bai

This is the document I also shared on my last reply. SLA-685 does not provide a complete, copy-paste-ready linker command file or an end-to-end, step-by-step procedure that shows how to relocate the IPE to a specific absolute address.

Hello Kenan,

I am so sorry but we really just have this material now. I think "let compiler handle memory partitioning" is easier and let us don't need spend time to manually handle it. Why you need to specify memory manually? 

I think the operation in the figure you shared with me is ok, but maybe you need to do some tests and try on your side.

Best Regards, 

Janz Bai

Hi Janz,

I agree that “let compiler handle memory partitioning” is convenient and avoids manual memory management. My concern is not about manually defining the IPE memory layout, but about address stability across builds when using OTA updates.

In my system, OTA updates only replace the application code in the field. The IPE region in FRAM remains unchanged on the device. The application calls IPE functions directly (normal C function calls).

My concern is this:
If the compiler/linker places IPE functions at different addresses across builds, then a new application image (built later) may be linked against different IPE function addresses than the ones actually present on the device. In that case, after OTA, the new application could jump to incorrect addresses inside FRAM, leading to undefined behavior.

So, this is not really an architectural preference on our side, but a hard requirement of the product: in the field, OTA updates can only update the application, while the IPE region has to remain unchanged.

I think this is a pretty common real-world scenario for many products using IPE and this situation may come up for many users. Having clear guidance or an officially recommended approach from TI on how to handle this safely is really important.

Best Regards,

Kenan Onat Kaplan

Hello Kenan,

I have got what you mean, so the key point is how to fix the address of these functions. Could you please try to check below link whether it can help you:

2.7.2. Function Attributes — TI Arm Clang Compiler Tools User's Guide

BR,

Janz Bai

Hello Janz,

I need to make a correction:

The key point is not how to fix the address of individual functions or a set of functions. Even if I pin specific functions to fixed addresses, if the IPE base address changes, those functions would end up outside the IPE region and would no longer execute correctly. Therefore, what needs to be fixed is the IPE region itself (its base and size), not the individual elements placed inside it.