SPC560Bx ECC Testing

[kevin239955_st]

Posted on September 29, 2015 at 16:48

Hi

We're trying to write a startup test for ECC detection using the EEGR register (table 524 of the reference manual RM0037). However it appears as if once a data inversion is forced (resulting in an IVOR 2 exception) it continues to occur following return from interrupt (rfi) regardless of ESR (and other ECSM register) clearing.

Is this expected behaviour, and/or is there a recommended sequence to recover from an EEGR-injected ECC error?

Thanks

Kevin

[Erwan YVIN]

Posted on October 06, 2015 at 17:16

Hello Kevin ,

I have forwarded the point with Experts.

        Best Regards

                         Erwan

[Erwan YVIN]

Posted on October 07, 2015 at 10:55

Hello Kevin ,

To recover from an EEGR-injected ECC error (1 Bit case)

i recommend you to use the vector 36 (cf screenshot).

and to create an error handler.

2 Bit cases are not recoverable , use vector 35

Did you try this ?

Best regards

Erwan

________________

Attachments :

2015-10-07_104824.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Pn&d=%2Fa%2F0X0000000bZa%2Fh6H5OCMMHCkju0fKR15.nalsbVekmVjqPh0Bj_7r8Wg&asPdf=false

[kevin239955_st]

Posted on October 27, 2015 at 16:53

Thanks for the response.

To recover the memory location needs to be written to and then read from to remove the error.

Regards

Kevin

[kevin239955_st]

Posted on March 23, 2016 at 18:17

Follow on question: should an ECC error raise an IVOR 01 or an IVOR 02 exception?

[EDIT] The IVOR 1 occurs during our IVOR 2 exception (because EE is cleared in the MSR) when we try to clear the ECC error, i.e. another ECC error occurs when we write to the error address.

Could you please tell us how to clear an error injected using the EEGR register (Table 524 of the SPC560Bx Reference Manual)?

Thanks

Kevin

[william23]

Posted on April 06, 2016 at 17:29

I've been working on this.

Currently we have the problem that our software will not recover from our ECC Test on the first run after a power cycle. If we reset the software (from within UDE) the ECC Test then works as expected.

Our test works as follows:

1) Write to the ECSM_EEGR register (0x0100) which should generate a single 2-bit ECC Error in RAM.

2) We then obtain the address of the error from the ECSM_REAR.

3) We then write some data to the address of the error.

4) We then attempt to read from the address of the error.

5) The read then triggers the IVOR 02.

6) We then clear the ECSM_EEGR and the ECSM_ESR

7) We then recover the affected memory address by writing then reading to it, this restores the memory.

8) We then return from Interrupt with the address in the SRR0

When running the software immediately from power on, the software goes to the interrupt on step 3 of the above. It clears the ECSM_EEGR and the ECSM_ESR and returns to that line of code, which it then tries to execute again but immediately instigates an IVOR 02. The second time into the IVOR 02 the ECSM_ESR and ECSM_EEGR are in a cleared state, indicating there is not any ECC errors. When we are in the IVOR 02 the ESR (Not the ECSM_ESR, the Exception Syndrome Register) has the following bits set. ST, VLEMI and XTE, the rest are not set.

After resetting the software, the software works in the order written above. However the ESR (Not the ECSM_ESR, the Exception Syndrome Register) has the following bits set. VLEMI and XTE. Meaning this ST bit is set in an IVOR 02 only after a power cycle and not after a reset.

According to the manual ST is a storage operation, which makes sense as the interrupt fires on a write command after power on and not on a read command like it does after a reset. However it lists the causes as alignment, data storage, data TLB, Program.

I'm hoping you can shed some light on why the interrupt fires on different occasions after a reset. If there are any other questions I can answer to help you get to the bottom of this I will be more than willing to answer them.

[william23]

Posted on April 07, 2016 at 15:24

Additionally, the Manual says the following:

''

For both types of memories (SRAM and flash), the intent is to generate errors during data

write cycles, such that subsequent reads of the corrupted address locations generate ECC

events, either single-bit corrections or double-bit non-correctable errors that are terminated

with an error response.

''

Which implies that:

1) EEGR is set

2) Write to error address from REAR

3) Read from error address (Interrupt fires here)

Problem we are having is that immediately after a power cycle the interrupt is firing on the write, which contradicts the manual.