eFuse controller: Is the ECC logic only active during the power-on reset sequence?

Hello Oliver,

 * QUESTION 1: But is the ECC logic also permanently active AFTER the power-on reset sequence? I.e. does the ECC logic also checks the ECC checksum of those registers (to which the eFuse values were shifted to) permanently, even AFTER the power-on reset sequence finished?

CT>> Let me give a bit background on the Efuse. The efuse cells are organized like a ROM memory and what we call as FuseROM. After power up reset the efuse controller will read the FuseROM word by word and shifts these words serially out in a scan chain to modules which are connected in the scan chain. Typically, flash banks, flash pump and SRAMs are connected in this scan chain. The shifting of the efuse values to these modules is what we call the autoload operation. When the fuse controller reads the FuseROM it will go through the ECC checking. This is similar to reading the memory from ATCM or BTCM where the reads will go through the ECC checking. The ECC checking is done on each word while the values are being shifted out. Once the efuse values are shifted out, they are latched by the respective modules. For example, FuseROM can contain some flash bank and pump trim values. After these trim values are shifted to the flash banks/pump they are stored in the banks/pump themselves. So to answer your question, after the power up reset, the ECC logic is still active but will not have a meaningful purpose because the efuse controller state machine has completed the reading from the FuseROM. It will not read the FuseROM again unless it goes through another power up reset.

 * QUESTION 2: In case the ECC logic is permanently active: Would a correctable or an uncorrectable error, which happened AFTER the power-on reset sequence finished, also trigger the corresponding ESM channels (i.e. ESM group 1, channel 40, and/or ESM group 3, channel 1)?

CT>> As explained above, after the autoload is complete, it means it has gone through ECC checking for each word of the FuseROM.

I've also a third question:
 * QUESTION 3: In case the ECC logic is NOT permanently active: Is there any mechanism with which could be detected that an unintended change of those registers (to which the eFuse values were shifted to) happened (e.g. cause of a bit flip)?
Reason for this 3rd question: IMHO a bit flip in one of those registers could lead to undesired system behaviour.

CT>> Once these efuse values are shifted to their respective modules, there is no more ECC checking for these values. For example, once the values are latched by the flash pump the pump module will not do another ECC checking. 

Hi Charles.

As always: I'm really thankful for your fast, understandable, and useful answers and feedback!

But still not everything is clear for me.

Regarding question 1: Answered.

Regarding question 2: Answered.

Regarding question 3: I understood your answer, i.e. the ECC checking is ONLY done during the autoload process. But it does not really answer my question. So I try to reformulate my question:

Question 3.1: Is there another mechanism (i.e. aside from an ECC mechanism) with which it would be possible to detect an unintended change of the eFuse data which was latched in the respective modules?

Reason for question 3.1: An unintended  change of the LATCHED eFuse data (e.g. cause of a possible bit flip, cause of cosmic radiation) could lead to UNDESIRED system behaviour. This undesired system behaviour could have tremendous negative effects especially for ASIL D projects. Additionally will increase the likelihood for a possible bit flip for industrial projects, which do not have a typical 8 hour driving cycle, but rather a 24/7 operating time for month.

So question 3.2 is: What is the suggestion of TI to detect a bit flip in the LATCHED eFuse data? As described above, this question is especially interesting for a 24/7, industrial project, with certification target ASIL D.

Regards

Oliver.