This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: TPS65381A-Q1
in the SafeTI™ Hercules™ Diagnostic Library Release Notes (v 2.4.0) there is the following known issue:
We develop a system in an industrial application which is running for several weeks or even months without restart (which would force ABIST / LBIST). From my point of view there is no possibility to guarantee that the TPS is working properly because it can't be tested anymore without the risk to get a power reset.
Do you have any idea for a workaround or an argumentation whether it is still useful in this application?
With kind regards,
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.
For more information on Multi-Channel Power Management ICs:
Find the right power solution for your processor or FPGA. Visit www.ti.com/SoCPower today!
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Scott Monroe:
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 Access2. Start ABIST3. Wait for ABIST completion (check ABIST_RUN)3a. Confirm that ABIST has run (ABIST_RUN has to be HIGH)4. Get ABIST test results5. 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 Register2. unlock SPI WR Access3. Start LBIST4. 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 results6. Restore SAFETY_CHECK_CTRL register7. 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?
In reply to Helge Pape:
If you run LBIST, ABIST is an automatic portion of the LBIST run and you will not see ABIST_RUN bit changing. A better description might be BIST instead of LBIST. During LBIST there is no way to run only LBIST but both BISTs run. During LBIST run many things are going on in the digital core even after the actual LBIST is done. The datasheet highlights no SPI activity should be made to the device during the whole BIST time of 21ms.
In your software you should avoid any SPI activity to the device for 21ms + 5% (22.05 ms). So after 22.05ms check if ABIST_ERR or LBIST_ERR indicated an issue or not.
Hopefully that helps. Please let us know if you have further questions.
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?
Hello Helge, Since the SPI may not be available during LBIST (or BIST) since when LBIST is run manually the ABIST is automatically run as well the easiest way to verify that LBIST ran was to double check one or more of the registers or bits that is re-initialized after LBIST is run and you may also observed that ENDRV will go low if it was HIGH (ENABLE_DRV set to 1 and conditions met to allow ENDRV to be HIGH). The list of LBIST re-initialized registers is in section 5.4.7 Logic Built-In Self-Test (LBIST) and 5.5.3 SPI Registers (SPI Mapped Response). ENABLE_DRV bit is in SAFETY_CHECK_CTRL which is re-initialized so bit that plus the watchdog failure counter may be the best options to monitor to confirm LBIST (BIST) ran depending on how you configure the other registers that will be re-initialized after LBIST (BIST). There are a couple of notes in the LBIST section highlighting the impact of the LIBST re-initializing these registers, including the watchdog fail counter, and the impact to ENDRV pin if LBIST is run during normal operation. If ABIST is run manually by itself the SPI registers will still work since it is only Analog portions of the device under test. We recommend not using the SPI during the LBIST (BIST) because to the MCU and software it is not really deterministic when the SPI read would be valid and when is a portion of the LBIST time where the SPI read may be invalid due to logic being under test. The best method of observation is to use the indirect methods of the ENDRV pin state assuming it was HIGH before the LIBST_EN was set and the re-initialized registers after the LIBST is complete. As noted in the datasheet, watchdog re-synchronization will be critical to re-establish before the WD_FAIL_CNT reaches 7+1 since it will be re-initialized to 5 by the LBIST run.
Best Regards, Scott
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.