S32K1xx - ECC check within FFTI (EIM)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K1xx - ECC check within FFTI (EIM)

1,323 Views
luca_toso
Contributor II

Hi All,

I already checked this post  and similar other bt I don't find a satisfying answer:

luca_toso_0-1624546718976.png

 

Does this mean that

- the software shall trigger an ECC event on SRAM once per FFTI using the EIM? or

-  the ECC (hence the register relevant for SRAM and FLASH errors) shall be checked once per FTTI?

I assume this is relevant only for double bit errors since they are not correctable. 

Thanks and B.R.

 

L.T. 

 

 

Tags (4)
0 Kudos
5 Replies

1,296 Views
ehtesham_khan
NXP Employee
NXP Employee

This is a recommendation for additional safety integrity on ECC Logic but not a requirement. If you think that this will impact your system performance it is OK to test it once at startup.

0 Kudos

1,271 Views
Susan_1
Contributor I
  • What is the impact of testing once at startup on PMHF,SPF,LF.

0 Kudos

1,260 Views
Yashwant_Singh
NXP Employee
NXP Employee

ECC has very little (almost negligible) contribution to single point fault and is considered primarily as a source of latent faults. So if you are running a check once every MPFDTI, then there should not be any noticeable change in SPF/LFM/PMHF. 

0 Kudos

1,304 Views
ehtesham_khan
NXP Employee
NXP Employee

This means the software shall trigger an event using EIM to check the ECC in SRAM and Flash and it should check the relevant register once per FTTI. The EIM can inject single bit as well as multi bit errors.

0 Kudos

1,315 Views
luca_toso
Contributor II

Up, because the topic is relevant for us. 

Triggering an ECC error via EIM once per FFTI is pretty invasive, in our opinion. 

Furthermore, due to the cortex m0 archtiecture the ECC on SRAM in the S32K1xx is first routed to the HardFault Handler and only then to the SRAM error ecc handler, and this is bothersome. If possible, avoiding it would be a pleasure. 

0 Kudos