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.

TPS65381A-Q1: Benefit of Q&A watchdog over window watchdog?

Part Number: TPS65381A-Q1

Dear support team of the power management forum,

(Q1) Which advantage offers the Q&A watchdog in tTPS65381 in TMS570 mode over a window watchdog?

(Q2) And does a Q&A watchdog give a kind of redundancy to the permanently running safe island HW-diagnostics of the Hercules microcontroller?
The idea behind (Q2) is that the computation of the answer to the watchdog might be wrong if a function in the safe island used for that computation has a random fault.

Thank you in advance for your support!

Stephan

  • Hi,

    Q&A watchdog gives higher fault coverage of the MCU compared to the Window watchdog.

    On Q2: I did not fully understand what do you mean by redundancy. Basically PMIC is expecting correct answers in correct sequence and timing from the MCU and if any random fault in the MCU which results in violation of PMIC Q&A watchdog requirements, PMIC detects it and takes appropriate action. I have looped in my colleague who supports this device for more details, if needed.

    Regards,

    Murthy

  • Hi Stephan,

    As Murphy mention the Q&A watchdog gives higher fault coverage of the MCU. 

    Also the way the Q&A watchdog routine is implemented in MCU will result in different level of software diagnostic coverage. For example is the software is reading the watchdog questions and calculates the correct answers as part of the routine this approach will have higher MCU software diagnostic coverage compared to a Q&A implementation using DMA based SPI transactions triggered by MCU timers. Using the DMA approach there is still a possibility that the software is stuck in an infinite loop and the MCU could still be sending the correct Q&A sequence.

    Finally, if the Watchdog is configured in Q&A mode then the MCU ERROR pin (which reports various error conditions on the MCU) can be monitored by the TPS65381A-Q1 ERROR input pin by configuring the ESM in TMS570 mode and allows the PMIC to transition to SAFE state if the MCU reports an error via the ERROR pin.

    Regards,
    Ivan

  • Hi, Ivan,

    All in All your answer matches my understanding of the benefits of a Q&A watchdog.

    But maybe there is another kind of redundancy besides the scenario you sketched in your post:
    Besides a software fault that could fire a Q/A WD a hardware error in the MCU could also fire the Q&A WD.

    Think of a random HW fault in the ALU (arithmetic and logic unit) in the MCU.
    Actually this kind of fault would be detected by the lockstep cores and signalised to the PMIC using the pins nERROR and ERROR/WDI.
    But what would happen if the nERROR = ERROR/WDI shows a stuck-at-high error?

    In the latter case there could be the possibility that the WD answer calculated by the MCU is wrong and thus the Q&A WD
    would increment the WD fail counter.

    This way of signaling a fault in the MCU using the Q&A WD may represent a redundancy to the signaling using the ERROR/WDI pin.
    Depending on how many elements in the MCU are used for calculating Q&A answers the extent of redundancy achieved by using a Q&A WD
    may be higher or lower. And i'm not sure whether calculating Q&A answers achieve a complete redundancy to the MCU diagnostics or not.

    So, Ivan, thank you again for confirming my understanding of the Q&A watchdog.

    Enjoy the day! Keep healthy!

    Stephan

  • Hi Stephan, 

    Thank you for describing a third option to use the QA WD to react to failures on the MCU nERROR pin. I do agree with your implementation and it should allow the application to react to nERROR stuck at high faults. In that scenario if the MCU detects a stuck-at-high fault  on the nERROR pin, the MCU can start sending incorrect Answers as fast as possible to minimize the time to disable the safing output ENDRV.

    Thank you for your feedback!

    Regards,
    Ivan