TPS65313-Q1: Why are SAFETY_ABIST_ERR_STAT5/6 bits set even if abist previously completed successfully?

Hi AnBer,

The device expert is currently out of the office until next week. They will look into this when they return. Please expect a delay in their response accordingly.

Thanks,
Field

Hi, after some further testing I can provide additional information:

It looks like that the Abist never completes in Active state for unkown reason

Hi Florian,

thank you for the information. I am currently looking into this.

regards,

Niko

Hi Florian,

could you check for any other errors when ABIST fails. Does ABIST fail also at turn-on? If it passes then try to run it again (without LBIST) and report the other possible errors that occur at the same time.

regards,

Niko

Hi Niko,

I figured out the following behavior:

Init --> Setup the configuration --> Run Abist in Diagnostic state --> success --> wait error counters count down and switch to Active state --> Run Abist in Active State --> Abist group start bits get never cleared in SAFETY_ABIST_CTRL ...

ABIST_SCHED_EN in Safety_cfg2 register is always cleared, because we do not want to use the Abist scheduler, instead trigger Abist manually by setting SAFETY_ABIST_CTRL

Florian

Hi Florian,

I am still looking into this and hopefully will get some results tomorrow. In the meantime try to manually toggle SAFETY_ABIST_CTRL bits down after writing. Also check what other possible error bits you get.

regards,

Niko

Hi Niko,

I have figured out several additional things:

(1) The behavior of incorrect setting of SAFETY_ABIST_ERR_STAT5 and SAFETY_ABIST_ERR_STAT6 bits is also present if using the Abist scheduler 

(2) Found one issue regarding the wrong setting of the safety abist bits:

For our application we do not use Buck2, the hardware connections for buck2 are:

BOOT2,PH2, VSUP2 not connected

VSENSE2 is connect to BUCK1 output with a resistor divider, so that VSENSE2 sees 1,2V

After changing all Buck2 relevant bits I managed to disabled Buck2 of the Sbc by clearing BUCK2_EN in PWR_CTRL Register

If this bit is cleared, the Abist error Bits get no longer set.

But still the Abist seems not to work correctly:

-  In Active State the Abist never completes, the SAFETY_ABIST_CTRL stay 1 and SAFETY_ABIST_ERR_STAT1 do not get set

- In Diagnostic state the Abist completes after ~300-400us,  SAFETY_ABIST_ERR_STAT1 get correctly set

The executed code for Abist run in Diagnostic and active state is the same, so why is it not working in Active state?

May this also be related to our hardware setup? 

Best regards

Florian

Hi Florian,

when executing the ABIST in ACTIVE can you check what safety errors or other errors you get?

regards,

Niko

Hi Niko, in the following list is a life status dump - the life dump is equal to the sticky dump, which starts after ENDRV set in active state:

DEV_REV 0x21 (Hex)
DEV_ID 0x10 (Hex)
DEV_STAT1 0x44 (Hex)
DEV_STAT2 0x0 (Hex)
VMON_UV_STAT 0x2 (Hex)
VMON_OV_STAT 0x0 (Hex)
EXT_VMON_STAT 0x0 (Hex)
SAFETY_BUCK1_STAT1 0x0 (Hex)
SAFETY_BUCK1_STAT2 0x0 (Hex)
SAFETY_BUCK2_STAT1 0x0 (Hex)
SAFETY_BUCK2_STAT2 0x0 (Hex)
SAFETY_BOOST_STAT1 0x0 (Hex)
SAFETY_BOOST_STAT2 0x0 (Hex)
SAFETY_ERR_STAT1 0x0 (Hex)
SAFETY_ERR_STAT2 0x0 (Hex)
SAFETY_ERR_STAT3 0x0 (Hex)
SAFETY_ERR_STAT4 0x0 (Hex)
SAFETY_ABIST_ERR_STAT1 0x0 (Hex)
SAFETY_ABIST_ERR_STAT2 0x0 (Hex)
SAFETY_ABIST_ERR_STAT3 0x0 (Hex)
SAFETY_ABIST_ERR_STAT4 0x0 (Hex)
SAFETY_ABIST_ERR_STAT5 0x0 (Hex)
SAFETY_ABIST_ERR_STAT6 0x0 (Hex)
SAFETY_LBIST_ERR_STAT 0x0 (Hex)
SAFETY_CLK_STAT 0x0 (Hex)
SAFETY_CLK_WARN_STAT 0x0 (Hex)
SPI_TRANSFER_STAT 0x0 (Hex)
WDT_STATUS 0x0 (Hex)
OFF_STATE_L_STAT 0x0 (Hex)

This data is also the same if Abist is not running. 

I see that BUCK2_UV is set in VMON_UV_STAT - Buck2 gets disabled at Init, so I dont know if this flag is set as intented.

Hope this helps

Florian

Edit: The Abist never completes, so it will get triggered multiple times in order to collect this data; otherwise due to infinity loop and not responding to Wdg / ESM the Sbc will enter Safestate

Hi Florian,

we are checking this issue further tomorrow and then I will get back to you.

regards,

Niko

Hi Niko,

do you have any updates for me?

After several more debugging and analyzing hours I found out that the Abist can complete after a very long time. At a closer look to this behavior I found out that the time correlates to the timing regarding the Abist scheduler. In our application the Abist scheduler is disabled, Safety_Cfg2 contains value 0x08 when active state is entered. Modifying Safety_Cfg8 also changes the Abist timing like if the Abist scheduler is enabled - but it is disabled.

(1) So is setting ABIST_SCHED_EN to 0 the correct value to disable the Abist scheduler?

(2) Is there a timing restriction regarding manually triggered Abist?

In our application we want to use the maximum watchdog trigger time, but run an Abist at least every 1 second - that is not possible with scheduled Abist, but from datasheet it looks like it should be possible with manually triggered Abist. From the things we found out it looks that there is a restriction that an Abist cannot be triggered manually more often then it would be possible with scheduled Abist - is that true?

Best regards

Florian

Hi Niko,

thanks for your reply, could you plase tell me the location in the datasheet where I can find this information:

"with closer inspection with the datasheet there is a mention that when ABIST run is manually started with SAFETY_ABIST_CTRL register, it enables the ABIST_SCHED_EN bit in SAFETY_CFG2 register. "

regards Florian

Hi Florian,

you can find this in section 8.16.1.1.1.10 SAFETY_CFG2 Register in the ABIST_SCHED_EN bit description. If you have any questions please let me know.

regards,

Niko

Hi Niko, 

thanks for this hint. I found the following description:

"1b = ABIST scheduler is enabled when the device is in the ACTIVE state and
if any of ABIST_GROUPx_START control bits in the SAFETY_ABIST_CTRL
register is set."

So I would understand that the Abist scheduler is enabled, if I set this bit to 1, move the statemachine to active state and then set ABIST_GROUPx_START bits.

But in fact the behavior seems like: Abist scheduler is enabled, if I set this bit to 1, move the statemachine to active state and then set ABIST_GROUPx_START bits OR if I set a any of ABIST_GROUPx_START control bits in the SAFETY_ABIST_CTRL in active state

Is this correct? - Will the scheduler be running all the time ? - This would mean that a manual single shot trigger for Abist is not possible? 

regards,

Florian

Hi Florian,

Yes your explanation is correct. If the device is in ACTIVE state and write any ABIST_GROUPx_START high it starts the scheduler and the scheduler delay. When this one ABIST is completed because the ABIST_GROUPx_START bit is cleared the ABIST won't run again until you initiate it again. This means that you can have a manual one shot ABIST run but from the moment the ABIST_GROUPx_START is written high the device waits for the ABIST_SCHED_DLY time until it actually runs the ABIST. Now you can set the ABIST_SCHED_DLY to the smallest value to have almost immediate ABIST run. Although in order to do this you have to lower the values in WDT_WIN1_CFG and WDT_WIN2_CFG registers (only in DIAGNOSTIC state) which changes the behavior of the watchdog.

regards,

Niko

Hi Niko,

thanks for your help. I think some more details about the Abist would help for better understanding the datasheet.

regards,

Florian

Hi Florian,

happy to help. If you don't have any more questions for now I will close this thread. You can also click 'This solved my problem' in one of my previous comments if you find that to be the case. 

regards,

Niko

Hi Florian,

Small correction to the behavior of the ABIST_SCHED_DLY with manual/single abist run when ABIST_SCHED_EN=0. The ABIST is actually run (and completed) immediately after ABIST_GROUPx_START bit has been set, but the device reports this completion (ABIST_GROUPx_DONE = 1 and clears ABIST_GROUPx_START) after the delay.

regards,

Niko