2401598_en-US

[#1]

Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code

Hello. I am currently developing based on the MPC5777C MCU.

I have a question regarding the development process.

I designed code to perform ECC checks based on the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code.

Under normal circumstances, this code performs the ECC checks correctly.

However, when running the ECC check code with a debugger like Trace32 connected to the MCU, errors often occur where bit errors are not detected.

Is it possible that the "GHS614" example code as a whole does not function correctly when connected to a debugger such as Trace32?

Thank you.

Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code

Hello.

Assuming the Trace32 debugger is connected and the dump window is open, and my custom application code is running, is it possible for a case to occur where a bit error is not detected within the ECC check function, which was designed referencing GHS614?

Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code

Hello,

I am not sure what your setup is, but have in mind that any open dump window in the Trace is constantly reading the memory and will rise the ECC fault immediately if detected.

ECC errors will never happen on the not corrupted address. As ECC mechanism is also guarded by EDC. Such is simply not possible.

Best regards,

Peter

Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code

Hello,

If the address which is read by SW or by debugger is corrupted ECC will always rise indepenant of example SW, or any other influences.

best regards,

Peter

Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code

Hello.

I will explain the situation in a little more detail.

My ECC check code execution is as follows:

(void)FCCU_ClearNCF();

/* 1-bit RAM data Error Injection */

GenerateRam1bitEccError();

uiErmSR0 = ERM.SR0.R;

uiErmSR1 = ERM.SR1.R;

uiErmSR2 = ERM.SR2.R;

/// 4. If a RAM 1-bit ECC Error occurs, perform the following.

if((((uiErmSR0 & ERM_SR0_1b_all) == ERM_SR0_1b_PRAMC_1) || ((uiErmSR2 & ERM_SR2_1b_all) == ERM_SR2_1b_Core1_data)) && ((uiErmSR1) == CLEAR))

{

/// 4.1. If the value stored in the ERM EAR Register is the same as the address where the error occurred, perform the following.

if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_PRAMC_1].EAR.R))

{

ucStatus = OK;

}

/// 4.2. If the value stored in the ERM EAR Register is not the same as the address where the error occurred, perform the following.

else if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_Core1_data].EAR.R))

{

ucStatus = OK;

}

else

{

ucStatus = NOT_OK

};

}

/// 5. If no RAM 1-bit ECC Error occurred, perform the following.

else

{

ucStatus = NOT_OK

};

This structure forcibly injects a 1-bit RAM Data Error and checks whether the ECC error occurred successfully and the address of occurrence was accurately detected.

If the Trace32 memory dump window is enabled while the above code is running, could the results of the ECC check be executed abnormally? (i.e., failure to detect ECC error or an error at the ECC occurrence address)

Thank you.