TPS65381A-Q1: SDOCM00107044 - TPS-Driver - Reset on enabling a ABIST and LBIST Run

Hello Helge,

You have posted to the PMIC forum supporting TPS65381A-Q1.  It is possible to manually by software run the ABIST and LBIST on the TPS65381A-Q1 while in DIAGNOSTIC or ACTIVE state by setting the LBIST_EN or ABIST_EN.  One note, running LBIST manually from software by setting LBIST_EN also runs ABIST as outlined in section 5.4.7 Logic Built-In Self-Test (LBIST) in the datasheet.  

There are key considerations when running LBIST or ABIST manually noted in this section of the datasheet:

1)  In the ACTIVE state the following considerations must be considered if a manual run of the LBIST is initiated by setting the LBIST_EN bit to 1. The LBIST should only be run in the ACTIVE state if the system-safety timing requirements can allow the total 21-ms BIST time and ENDRV being low for the 21-ms time.

2)  After the LBIST is complete the WD_FAIL_CNT[2:0] counter is re-initialized to 5. The MCU should resynchronize to the TPS65381A-Q1 watchdog by writing to the WD_WIN1_CFG or WD_WIN2_CFG register or by immediately causing a bad event. Both of these resynchronization options start a new watchdog sequence and increment the WD_FAIL_CNT[2:0] counter. If the WD_RST_EN bit is set to 1 (enabled), the watchdog service routine in the MCU must ensure good events are sent to the watchdog to start decrementing the WD_FAIL_CNT[2:0] counter before it reaches 7 +1 which cause a transition to the RESET state.

3) from section 5.4.6 Analog Built-In Self-Test (ABIST):  During an ABIST run, the device cannot monitor the state of the regulated supplies, and the ENDRV pin is pulled low. The ABIST run time is approximately 300 μs. The ABIST can be performed in the ACTIVE state on an MCU request, depending on system safety requirements (such as a system-fault response time), ENDRV pin will be low during ABIST run.

I suspect the test run from the Hercules driver team didn't realize these constraints while they had the WD_RST_EN bit set to 1 and the watchdog failures causes the TPS65381A-Q1 to transition through it's RESET state which pull NRES low and would normally reset the Hercules.

You may want to post to the Hercules forum in parallel and ask if there is an update to the driver that will re-synchronize the WD after running LBIST or you may need to do that separately in your application code.

I will contact them in parallel.

Scott

Thank you for your support. I look forward to get the feedback of the Hercules Team.

I made an additional post as you suggested: "TMS570LS1114: SDOCM00107044 - TPS-Driver - Reset on enabling a ABIST and LBIST Run".

With kind regards,
Helge

Hello Scott,

do you have any new information concerning the power reset while LBIST or ABIST testing?

Now I am able to execute ABIST with expected results:

1. unlock SPI WR Access
2. Start ABIST
3. Wait for ABIST completion (check ABIST_RUN)
3a. Confirm that ABIST has run (ABIST_RUN has to be HIGH)
4. Get ABIST test results
5. lock SPI WR Access

ABIST takes 300us as described in Manual.

For the LBIST I am doing nearly the same procedure:

1. Safe SAFETY_CHECK_CTRL Register
2. unlock SPI WR Access
3. Start LBIST
4. Wait for LBIST and ABIST to complete (check ABIST_RUN and LBIST_RUN)
4a. I manipulate the SPI results of TPS Registers if they are unavailable so that the result is 0xA002 (0xA0 = Command Phase, 0x01 = Data Phase (D1 = 1 --> LBIST_RUN))
4b. Confirm that LBIST and ABIST have run (LBIST_RUN and ABIST_RUN have to be HIGH --> here: I do not get the ABIST_RUN)
5. Get ABIST and LBIST test results
6. Restore SAFETY_CHECK_CTRL register
7. Configure watchdog window for synchronizing TPS and TMS (the SafeTI Lib API "TPS_ConfigureWatchdogWindows()" asks for TPS device state to be in DIAGNOSTIC which is NOT necessary here [ABIST and LBIST can be run in ACTIVE state also]; the API "TPS_ConfigureSafetyCheckControl()" also asks for TPS device state to be in DIAGNOSTIC, so no CRC check could be enabled while TPS is in ACTIVE state)
8. lock SPI WR access

My LBIST duration is only 4.6ms. This means that LBIST_RUN is only HIGH for 4.2ms LBIST duration and not during the whole LBIST test (4.2ms LBIST + 16ms wait time (inluding 300us ABIST)). Is this correct? Because the manual says "After the LBIST run, completion of the whole BIST is confirmed by the MCU by reading 0 for both the LBIST_RUN and ABIST_RUN bits." This is what I get after 4.6ms.

When is the ABIST exactly executed during wait time? Do I have to read out the whole 16ms wait time to get the ABIST_RUN bit?

When are the results (LBIST_ERR and ABIST_ERR) valid? LBIST_ERR valid after 4.2ms or after 4.2+16ms? ABIST_ERR valid after 4.2ms+16ms?

Best regards,
Helge

Hello Scott,

In the TPS65381A-Q1 Datasheet it is said that "The SPI registers may be unavailable during a BIST, so no SPI reads or writes should be made while the BIST is running". During ABIST I could not discover this behaviour while asking for ABIST_EN, ABIST_RUN and ABIST_ERR flags. All are set in the right manner.

But during LBIST execution the SPI receives 0xFFFF (as described in data sheet). If I couldn't get the LBIST_RUN flag how can I be sure that the LBIST was really executed? If I do not get the LBIST_RUN flag I can not trust the result in LBIST_ERR because it is initialized with 0 (no error). There are two possibilities: 1) LBIST was really run but detected no error. 2) LBIST has not run so there is no change in LBIST_ERR.

Following your former statement, after LBIST_EN is set I only have to wait 22.05ms and have to assume the LBIST was executed, am I right?

So the statement of the data sheet is not applicable here because during an LBIST the SPI Registers are not accessible and if the LBIST is complete LBIST_RUN and ABIST_RUN are 0 anyway:

Is it a problem for TPS if I do SPI transmissions while ABIST and LBIST (regarding the TPS power reset or any other issues) are running?

Best Regards,

Helge