- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Thanks. If I should create this as a new follow up question, I can do that.
But even if that ESM group3 check was handled in software, all that handling the check could do is report the fail to pass that check, correct? It's not like there's a software action that could be taken to resolve the ESM group3 fault? It would just fail more gracefully.
Andrew,
The specific fault in group3 that you reported has to do with the auto-load (scan in) operation by the on-chip eFuse controller.
Above figure shows part of the power-up sequence. The eFuse auto-load operation is triggered once the oscillator reports as "valid". This is just based on a counter that counts down 1032 oscillator cycles, which in turn is triggered by the release of nPORRST by the external supply supervisor.
The eFuse scan also checked by its own ECC logic during this auto-load operation. If you don't get the eFuse auto-load error on every single power-up (or each time you assert and release nPORRST), I would suspect either the power supply stability or the main oscillator clock stability. If you do get the auto-load error on each power-up, you could run the eFuse ECC logic self-test and see if it fails. If the ECC logic checks out ok, there could be something indeed wrong with the eFuses.
All silicon components have a non-zero failure rate. The main purpose of the safety mechanisms designed on-chip and at the system-level is to detect these failures and respond to them before they can cause harm.
Hope this helps.
Regards, Sunil
