FS4503: ABIST1 fail without apparent reason. Any pointers for what to test next?

[Joey_van_Hummel]

Hi all,

One of our prototypes has failed and the effect seems to be FS4503 pulling fs0b low. Upon diagnosing further, ABIST1 is failing, but I can't figure out why.

According to the datasheet (Rev. 7.0), in ABIST1 the following is checked:

So I have checked the mentioned voltage rails and they are fine.They rise within 10 ms from power-on which is well within the spec'd time before ABIST1 starts. Voltages are stable and stay stable.

The power supplies' DIAG registers (DIAG_CPRE, DIAG_VCORE, DIAG_VCCA, DIAG_VAUX, DIAG_VSUP_VCAN) show no faults (only undervolt directly after power-on, but only for 1 read. After that one read, no errors at all.) So no UV, OV or ILIM or TWARN present.

The DIAG_SF_IOs register shows that there are no IO faults (Rstb_Diag, Fs0b_Diag are both 00, as are other faults). Further, DIAG_SF_ERR shows no apparent faults (FltErr is 2 as expected with ABIST1 failing, but V2p5_M_A_Ov, V2p5_M_D_Ov, Fcrbm_Ov and Fcrbm_Uv are 0).

In short: according to the table, ABIST1 should not be failing. Am I missing something? Does anyone have any pointers as to what else to test for?

Kind regards,

Joey

[autolan22]

Hi Joey,

I got an ABIST1 fail too.

You mentioned: "So I have checked the mentioned voltage rails and they are fine.They rise within 10 ms from power-on which is well within the spec'd time before ABIST1 starts. Voltages are stable and stay stable."

It's inspired me.

I want to do the same check as you did but I looked through all the manual and still couldn't find "the spec'd time before ABIST1 starts".

Though my chip is FS26, I still want to know which part of the FS4503 datasheet has mentioned this spec'd time?

Best regards

[Joey_van_Hummel]

Hi,

I don't remember exactly where I found any specced time. I think I inferred it from TRSTB_POR in the datasheet. If you check the following diagram, you can see ABIST1 is done after approximately 16.5 ms.:

This time coincides with 12.5 to 24.3 ms for TRSTB_POR:

So it's not exact science, and I might have been wrong.

Kind regards,

Joey

[autolan22]

Hi Joey,

I appreciate your generous sharing.

Hope you have a nice day!

Best regards

[MNN]

Hello, I also encountered this problem, I also use FS26. May I ask what problem you have caused this phenomenon, and where can I solve it?

[autolan22]

Hi,

What I eventually found out was that we had a channel whose voltage did not meet the ABIST PASS criteria stated in the manual during ABIST execution.
In FS26 datasheet's "Figure 18. Power-up example .....", we can found the 300us before the release of the RSTB pin is the execution time of ABIST.

Maybe you can use an oscilloscope to observe whether the various voltages monitored by ABIST within 300us before the release of the RSTB pin are up to standard to try to find the cause and solve it.

Best regards

[Joey_van_Hummel]

Hi,

Thanks so much for sharing. After more than a year we finally have an explanation for our ABIST1 issue.

It turns out that even though RSTB_DIAG is 0, and even though the microcontroller could be programmed, RSTB is low ohmic (ca. 90 Ohms) to 5V, and never reaches lower than about 3.3V. It turns out the microcontroller had developed an internal short over time.

@TomasVaverka, is it possible for RSTB_DIAG to be 0, even though RSTB is stuck to high during ABIST1? What are the conditions for RSTB_DIAG to be set? It seems like RSTB_DIAG is only a momentary bit, based on current conditions, and not sticky, based on past events?

Kind regards,

Joey

[TomasVaverka · Accepted solution]

Hi Joey,

All the items that are being checked during the ABIST1 are shown in Table 31 of the Safety Manual. Furthermore, please check what is IO2, IO3 voltage, it should be smaller than 8V.

Best regards,

Tomas

[Joey_van_Hummel]

Hi Tomas,

Thanks for your reply and the attached table. I have checked IO2 and IO3, they are pulled down to GND with 5k1 resistors and their voltage correctly measures as 0V.

So considering all other regulators don't indicate a failure on their diagnostics, I think the only thing left would be internal failure of the fail-safe oscillator or the failsafe V2P5 digital/analog. Sadly there seems to be no way to check those from the diagnostics registers over SPI.