Hello,
In the eFuse module, before starting the stuck-at-zero test, the following bits are already being shown as set(1) in the EFC Boundary Control Register:
- EFC Self Test Error
- EFC Single Bit Error
- EFC Instruction Error
- EFC Autoload Error
Because of this, the stuck-at-zero test is failing. What could be the reason for all these bits to be set at once? And is there any way to reset these bits?
Hi,
Is this something you observe on only one board or all the boards you have?
What is the bit setting for bit 17, 16, 15 and 14 when you see all the mentioned errors?
After power up and before you start the stuck at zero test, did you check if you are getting any errors per instructions in the TRM. Please see below.
32.3.2 Checking for eFuse Errors After Power Up
For safety critical systems, it is required that you check the status of the eFuse controller after a device
reset. A suggested flow chart for checking the eFuse controller after device reset is shown in Figure 32-1.
Failures during the eFuse self test can be grouped into three levels of severity. Depending on the safety
critical application, the error handling for each error type may be different.
32.3.2.1 Class 1 Error
A class 1 error of the eFuse controller means that there was a failure during the autoload sequence. The
values read from the eFuses cannot be relied on. All device operation is suspect. A class 1 error is
indicated by a signal to group 3 channel 1 of the ESM. This will cause the ERROR pin to go active low.
32.3.2.2 Class 2 Errors
A class 2 error is an indication that the safety checks of the eFuse controller did not work. These are also
serious errors because you can no longer guarantee that a more severe error did not occur.
32.3.2.3 Class 3 Error
A class 3 error indicates that there was a single bit failure reading the eFuses that was corrected by ECC
bits. Proper operation is still likely, but the system is now at a higher risk for a future non-correctable error.
When a correctable error occurs, ESM group 1, channel 40 will be set. In the suggested flow chart shown
in Figure 32-1 below, the single bit error is determined by directly reading the eFuse error status register,
and not depending on the integrity of the connections between the eFuse controller and the ESM.
Hi Rishi,
Bit 17-14 are 0 after reset by default. You might have set them before you start the suck-at-zero test. Can you first clear all the bits in EFCBOUND register first and then start the stuck-at-zero test by following the below instructions.
Hi,
I suspect that you use HalcoGen as a reference to build your project. In HalCoGen the Efuse Selftest is enabled. This is why your bit 17-14 are already set before you start the stuck-at-zero test. Please confirm if this is the case.
If you have not run any Selftest earlier, the EFCBOUND and EFCPINS registers should look like below after power up where you can see the EFCBOUND register is all zeros and the care-about bits in EFCPINS are also zeros.
As I mention, you can clear EFCBOUND register manually before launching your stuck-at-zero test had you already run Efuse Seltest earlier from HalCoGen startup.
