AM263P4-Q1: Method for checking for faults on the communication path to external flash memory using the FSS ECC function during program loading.

Hi Atsuki,
I will check and will get back to you

Hi Imada,
I was OOO for a while, allow me to check this and get back asap

Thanks & Regards,

Aswin

Hi Imada,

Yes, ECC Can Detect Faults During Program Load from External Flash
The FSS ECCM (Error Correction Code Memory) provides SECDED (Single Error Correction, Double Error Detection) protection on the data path to/from external flash via OSPI.

Your Proposed Approach Is Correct, this is the correct sequence. But you need to ensure the data in flash has ECCM also attached to it.

Required Sequence

  1. FSS_disableECC()           // Ensure clean state
  2. FSS_configECCMRegion()     // Define 4 regions (start + size, 32-byte aligned)
  3. FSS_enableECC()            // Enable ECCM engine globally
  4. Bootloader_parseAndLoadMultiCoreELF()  // Load with ECC active

To enable the interrupts, please make use of the below sequence

1. FSS_FSAS_GENREGS_SYSCONFIG

- Make sure ECC_EN is set - Set ECC_EN as 1

- Disable prefetcher - Set DISXIP as 1

- Set FSS_AES_EN_IPCFG as 0

2. Configure the ECCM regions

3. Configure ESM interrupt for ESM_INTR_LEVEL_FSAS_ECC_INTR

Do let me know if you are facing any issues

Thanks & Regards,

Aswin

Hi Aswin,

To check for faults on the communication path with external Flash when loading a program into RAM, I executed the following sequence of operations using the ECC function:

1. FSS_disableECC() // Ensure clean state
2. FSS_configECCMRegion() // Define 4 regions (start + size, 32-byte aligned)
3. FSS_enableECC() // Enable ECCM engine globally
4. Bootloader_parseAndLoadMultiCoreELF() // Load with ECC active

However, `Bootloader_parseAndLoadMultiCoreELF()` returned -1 (`SystemP_FAILURE`).
Please explain the cause of this -1 (`SystemP_FAILURE`) return value and the appropriate next steps to take.

Details regarding the environment are provided below.

The SBL environment is based on the sample code (`sbl_ospi_multicore_elf`). I have added steps 1 through 3 prior to calling `Bootloader_parseAndLoadMultiCoreELF()`.

The application is also based on the sample code `examples\benchmarks\ocmc_benchmarking`. ECCM is enabled using the `conf.json` file shown below. I have verified using `tiarmreadelf` that ECC bytes have been added to the generated MCELF file. Additionally, I have confirmed that when using this MCELF file with an SBL that does *not* include the added steps 1–3, `Bootloader_parseAndLoadMultiCoreELF()` returns 0 (`SystemP_SUCCESS`).

conf.json:
{
"regions": [
{
"start": "0x60100000",
"size": "0x400000",
"cryptoMode":"na",
"eccEnable": true
}
]
}

In the SBL, the `regionConfig` passed to `FSS_configECCMRegion()` is set as follows, matching the `conf.json` used:

FSS_ECCRegionConfig regionConfig;
regionConfig.size = 0x400000;
regionConfig.startAddress = 0x00100000;
regionConfig.regionIndex = 0;

Requested response date: October 9, 2026

Hi Imada,

The script only enables ecc on mcelf_xip image. The mcelf image wont be ecc enabled. So if you configure ECC before Bootloader_parseAndLoadMultiCoreELF() without enabling ecc on mcelf image, the Bootloader_parseAndLoadMultiCoreELF() is bound to fail.

I am trying to enable ecc on mcelf image, but is facing some issues with this. Currently ECCM is working on the xip image.

Did you enable the ECC on mcelf image for your test?

Hi Imada,

While enabling ECCM on a non-XIP flash region is theoretically possible, the implementation challenges, software complexity, and toolchain disruptions are significant.

Here is a detailed breakdown of the technical impacts:

1. Address Translation Complexity

Enabling ECCM expands the physical memory footprint by 12.5% (32 bytes of data + 4 bytes of ECC = 36 physical bytes per 32 logical bytes). This introduces a non-linear mapping between the CPU's logical address space and actual physical flash:

Address in Flash  = 0x6000_0000+ (Offset in Flash)*9/8.

Suppose we configure the SBL to look for the application at 0x10_0000 offset in flash.

While flashing the application, since we are enabling ECCM on Non XIP aka MCELF region, the application MCELF image should be flashed at 0x6012_0000. This is because, we cannot write with ECCM enabled. Once ECCM is enabled, the entire image will appear at 0x6010_0000. 

2. Comprehensive MCELF Struct Rewriting

Because this expansion applies across the entire region, the nested offsets within the MCELF layout must be entirely reconstructed. Scaling affects multiple metadata layers:

The SBL relies on the ELF Headers and PHT to find the Load segments. The address/offset of these segments are calculated without considering flash ECCM. That is in the standard way. In this case, the entire offsets in ELF HEADERS and PHT should also be scaled by 12.5%. So this logic needs to be added in the script of ELF lib.

3. Harcoding OTFA note segment in SBL

In current implementation, the SBL relies on note segment to enable ECCM on flash. Note segment is read from flash. Since we are embedding ECCM on the Non XIP region completely, we would need to hardcode the note segments params in SBL itself. This might be okay in normal scenario, but needs to be assessed in cases were AB swap is used.

Suggested Alternative

In production software, if we are using HSM, then HSM authenticates the non XIP region aka the mcelf file. Any disruption in the data will be caught by the HSM during image authentication. Additionally, RAM ECC would also be there.

ECCM can be enabled on XIP region. This can be done using the current SDK offering. You can test by enabling it on hello world xip example

Thus we have protection on both XIP and Non XIP files regions.

Hi Aswin,

Thank you for the information. I understand that ECC needs to be enabled for the mcelf image as well.
I had been conducting tests in an environment where ECC was enabled only for the mcelf_xip image.

I would like to receive the environment setup that enables ECC for the mcelf image by October 13th.
Please let me know if there is any information you require from us.
Imada

Hi Imada, 
I mentioned the challenges in implementation and tooling that will be required to enable ECC on mcelf image as well.

Instead of that, having HSM authenticate the mcelf image (which already is being done) would be sufficient. 

Could you please evaluate the suggested alternative and kindly provide me a feedback on that?

Suggested Alternative

In production software, if we are using HSM, then HSM authenticates the non XIP region aka the mcelf file. Any disruption in the data will be caught by the HSM during image authentication. Additionally, RAM ECC would also be there.

ECCM can be enabled on XIP region. This can be done using the current SDK offering. You can test by enabling it on hello world xip example

Thus we have protection on both XIP and Non XIP files regions.

Thanks & Regards,

Aswin

Hi Aswin,

I understand the technical implications of enabling ECCM in the non-XIP region. Even taking those into account, I would like you to prioritize providing an environment (or script) to enable ECC for the mcelf image over exploring alternative solutions.

I would like to receive this as soon as possible; how long would it take?

---

I have a few points I would like to clarify regarding the proposed alternative solution:
・Our objective is to detect faults (*) occurring on the communication path to the external flash memory. Is this possible using the HSM?

*: We want to detect anomalies in cases where, for example, correct data is written to the flash, but the data value changes during transmission, causing the CPU to load incorrect data.

・When using the HSM to authenticate the non-XIP region (mcelf file), is it possible to identify which core's program (or data) contains the error?

Imada

ATSUKI IMADA said:

Our objective is to detect faults (*) occurring on the communication path to the external flash memory. Is this possible using the HSM?

ECCM will help to detect any anomalies in reads from Flash, not to writes. Any anomalies in the image will be captured by the HSM.

ATSUKI IMADA said:

When using the HSM to authenticate the non-XIP region (mcelf file), is it possible to identify which core's program (or data) contains the error?

Authentication will fail when there is any anomaly in the image, but it lacks pointing out the region with error

ATSUKI IMADA said:

I understand the technical implications of enabling ECCM in the non-XIP region. Even taking those into account, I would like you to prioritize providing an environment (or script) to enable ECC for the mcelf image over exploring alternative solutions.

I would like to receive this as soon as possible; how long would it take?

As I mentioned above the feature has some technical implications. So this would count a requirement and I can check to get this implemented in the next release of SDK.

I have raised a requirement on this, link for internal tracking: https://jira.itg.ti.com/browse/MCUSDK-16038

Thanks & Regards,

Aswin

Hi Aswin,

I understand that enabling ECCM in non-XIP regions is not supported in SDK 11.
Please explain how to use the HSM.

Configuration
● AM263Px MCU + SDK: 11.00.00.19
● CCS: 20.3.0.00014
● Device: HS_FS

Conditions
● Valid data has been written to the external flash.
● Errors must be detectable if data corruption occurs on the transmission path during reads from the external flash.
● There is no need to identify the specific region where the error occurred.

Points to Confirm
● Which HSM service should be used to achieve this?

Note: I am referring to the following documentation page:
software-dl.ti.com/.../DRIVERS_HSMCLIENT_PAGE.html

● Could you please point me to where usage examples are provided? Also, would it be possible to get some sample code?
● Is this achievable on the HS_FS device as well?

Requested Response Date: 2026/10/19

Note: Please contact me if the response will be delayed or if additional information is required.

Imada

Hi Imada,

You requirements can be satisfied with a combination of HSM and Flash ECCM. 

1. Detecting data corruption on image written in Flash

a. Detecting data corruption on XIP images - mcelf_xip image

This can be done exactly how it is done now. By enabling ECCM on the flash region where XIP image is stored

b. Detecting data corruption on non-XIP images - mcelf image

This can be done with the help of HSM. I can provide more details on this. But before that can you please confirm the production device state?

Is it HS-SE or HS-FS for production? The HSM validating the image is only possible in HS-SE device state, not possible in HS-FS 

2. Detecting data corruption on data written in Flash

To find errors in normal data written in flash also the method 1.a can be used. You can enable ECCM on the required flash region. 

Thanks & Regards,

Aswin

Hi Aswin,

> But before that, could you please confirm the state of the production device?

In the future, we will switch it to the HS-SE state.

Could you please provide details on how to utilize the HSM for error detection?

Also—and I apologize for asking again—is it correct to understand that, assuming the image written to the external flash memory is free of errors, the system can detect errors if data corruption occurs on the transmission path during a read operation from the external flash?

Requested response date: October 22, 2026

Imada

Hi Imada,

Apologies for the delay. In HS-SE, the Proc Auth Boot Service can be used to validate the application. More details on the service is mentioned in the TIFS User guide. Please check the TIFS user manual.

ATSUKI IMADA said:

Also—and I apologize for asking again—is it correct to understand that, assuming the image written to the external flash memory is free of errors, the system can detect errors if data corruption occurs on the transmission path during a read operation from the external flash?

To be precise, the SBL will copy the image from flash to RAM and will ask HSM to authenticate. The HSM SW can catch irregularities in the image during its authentication service. So any issues that occurred inside flash or during the image transit to MCU will be caught by the HSM when after it authenticates the image that is copied into RAM.