AM2434: ECC injection error failed when the APP was running in DDR

Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

Env:

CCS:18.1

SDK:mcu_plus_sdk_am243x_11_00_00_15

Refer:

C:\ti\mcu_plus_sdk_am243x_11_00_00_15\examples\drivers\ddr\ddr_ecc_test_main_esm\am243x-evm

 

Running the ECC routine can inject errors normally and detect them.

In our APP, injection will be directly interrupted by error.

 

Our APP code runs in DDR.

Initialize the DDR in the Bootloader and enable ECC, with the starting address avoiding the APP code area

Conduct injection tests in the App. It was found that once injected, it would be wrongly interrupted

 

Boot sysconfig:

 The maximum address of the ddr part of Boot map:

 The maximum address of the ddr section of the APP map:

 The incoming injection address:

 The question is: Will running the APP in DDR prevent injection testing? Whether the configured ECC area avoids the APP area or not?

Thanks!

 

  • Yes, the injection tested was intended to be run from a memory other than the DDR.  Check the original code in the MCU+ SDK, i believe the example test runs from internal memory.

    Regards,

    James

  • Hi JJD,

    For scenarios where the code is running in DDR, the currently configured DDR space does not overlap with the code's DDR space. However, why does toggling the DDR ECC function affect the code execution?
    When ECC is enabled, the mapping relationship between all physical addresses and logical addresses of DDR changes, including the region where ECC is not enabled, then lead to code tearing?

  • Based on the description in the TRM, it matches my speculation above. 



    Additionally, I verified it through testing: using the ddr_ecc_test example, the address mapping of the unprotected region (0x80000000~0x80000FFF) changed before and after toggling ECC.



    So, is there any other way to trigger an ECC error, for example by modifying registers?

  • That is correct, with ECC enabled, the whole memory physical addressing gets restructured as shown below:

    To trigger the ECC error, you should be able to follow the sequence in the example code.  I haven't looked at it in detail, but it should disable ECC to inject the error at a specific physical address, then reenable and execute.

    Regards,

    James

  • Yes, the example's approach is to disable ECC, modify the data, re-enable ECC, and then read the data to trigger an ECC error.

    However, in the example, the code runs in MRAM, so when ECC is enabled or disabled, the remapping of DDR logical addresses does not affect code execution. Our code runs in DDR, and the address remapping that occurs when enabling or disabling ECC would cause code tearing and a crash.

    I have found a solution: ensure that the code for enabling/disabling ECC and injecting errors is placed within the first 256 bytes of DDR, and disable interrupts during this process. This way, during the process of disabling and enabling ECC, the code executed by the CPU experiences neither tearing nor remapping — tests show this approach works.

  • Ok, thanks for posting the solution.  Yes i think the remapping between enabling/disabling would not work, other than at the beginning of the address space, where the remapping and physical address would be the same regardless of enable/disable of ECC.

    Thanks

    James