TPS65381-Q1 RESET conditions

Leonard,

The appropriate applications engineer has been notified of your post and will respond as soon as they're available.

Regards,

Are you using the TMS570 libraries? If so we may need to involve the TMS570 team. I will answer from the TPS65381-Q1 perspective.

Q1. When the TPS65381 RESETs the TMS570, how can I read the TPS65381 to determine the cause of the REST?

A1: when the TPS65381 device goes through RESET state and thus pulls NRES to RESET the TMS570 the status flags will be re-initialized after RESET state is cleared and DIAGNOSTIC state is entered. There is no easy way to determine what caused the RESET on TPS65381. One way to "predict" the cause is to monitor the WD_FAIL_CNT, if it increments all the way to 7, the device is one WD "bad event" away from RESET.

Q2. While in DIAGNOSTIC Mode, the WD Counter is set/serviced to '0'; the TPS65381 is then changed to ACTIVE Mode, a RESET is immediately generated. Why would this happen and what can be done to prevent this RESET?

A2: I do not think that is what is really happening, it shouldn't. There are a few other things that could go wrong with the transition to ACTIVE. Please make sure you are looking at datasheet Rev F sections 5.4.1.20, 5.4.1.23. There is a DIAGNOSTIC State TIME-OUT, if DIAG_EXIT_MASK bit was used to stay in DIAGNOSTIC state and the DIAGNOSTIC State Time-out has occurred (it still runs in the background but will not cause the state change to SAFE due to the timeout), the bits WD_FAIL bit and ERROR_PIN_FAIL. If these are not cleared when DIAG_EXIT_MASK is cleared and DIAG_EXIT is set (in the same SPI register write) the device will go to SAFE. There should be no other immediate change on the request to ACTIVE assuming the WD_FAIL_CNT really is at 0. The WD_FAIL_CNT will re-initialize to 5 on the state change from DIAGNOSTIC to ACITVE, but the device should not go through RESET state. Is the software remaining sync'd to the TPS65381 and providing the proper watchdog triggers or answers (depending on WD Mode)? You should be able to monitor WD_FAIL_CNT and see it re-initialize to 5 and then if there are fails (either bad triggers/answers or timeout) it will increment from 5 to 7 and on the next bad event will cause RESET.


Q3. Related to 2, WD_RST_EN is set to 0, INIT routine for the TPS65381 is performed and without changing WD_RST_EN, a RESET is still generated. What would cause this RESET to occur?

A3: The WD will not cause RESET unless WD_RST_EN is set to 1. There are other sources for RESET. Please note if WF_RST_EN has been set to 1, it will remain set to 1 after RESET. If the WD is not serviced in time and three timeouts or bad events occur (ie incrementing to 6, 7, 7+1) after RESET is released the WD would "fail" again and cause RESET again. The possible sources for RESET are outlined in Figure 5-14, section 5.4.1.20 and 5.4.1.22.

Q4. When a SEQ_ERR occurs, is there a register in the TPS65381 to inform as to the data received?

A4: No, there is no way to read back the "received" watchdog answer-byte. The MCU should ensure the Question counter is WDT_ANSW_CNT[1:0] is at 3 at the start of the watchdog sequence. That way you know the MCU answers are aligned to the TPS65381-Q1 watchdog.

Scott

Hello Scott,

Thanks, I appreciate the quick response. We're mulling over how it maps to what we were seeing.

Some odd and ends:

1) Yes, we are using the TPS Driver library for Hercules Microcontrollers, version 2.2.0.

2) I accept that the TPS65381 is what it is, but I'm surprised that there isn't a feature for getting some information about why the TPS transitioned into STANDBY or RESET states; I would expect that other customers besides ourselves would be interested in this capability. As you noted there are multiple sources for RESET.

Similarly, although I appreciate it isn't necessary for correct interfacing with the TPS, allowing readback on the WDT_ANSWER register would have been an appreciated addition to the chip.

Is this forum a good venue for providing feedback about the TPS?

3) I hadn't appreciated that WD_RST_EN wasn't being reset upon entry into the RESET state (although that certainly makes sense). Is there a list or just a simple description of what TPS registers are changed when the TPS goes through the RESET?

DEV_ERR_CNT is not reset, other than that, are all of the status registers reset?

Are most of the configuration registers preserved? Is ENABLE_DRV reset?

I see the LBIST list in 5.4.1.6; does this completely cover any impact on registers when going through RESET? What is AUTO_BIST_DIS is set? Do all the registers remain unchanged? (When not passing through STANDBY.)

Thank you!