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: TPS65381A : external rail brownout pulls reset line low causing mismatch on NRES pin

Part Number: TPS65381A-Q1

Hello
We are looking at the TPS65381 in more detail and have some questions about brownout operation

If the power supply circuitry (independent of the companion chip) pulls the NRES pin low thus halting the processor, the companion chip will detect this and go to a safe state. The companion chip will remain in a safe state. If the power to the processor returns the NRES pin is released and it reboots the processor. (The ENDRV pin will be low thus keeping the system safe) The processor will need to restore the companion chip to a state that we can restart the system again. Can this be done ? how ? Or am I correct in thinking that the only way out is by cycling the power to the companion chip or the IGN pin.

 

We may take the decision that the complete unit will require a full power cycle after a brown out. But for the time being  we would like to make a recovery after a brown out, requiring a restart signal to proceed, avoiding a full power cycle

 

Many Thanks
Bob Bacon

  • Hi Bob,

    I've assigned this post to the appropriate applications engineer, he will respond to your question.

    Regards,
    Karl
  • Hi Bob,

    Please make sure you and the customer are looking at the latest datasheet for the TPS65381A-Q1 where the SAFE state-time out is clearly defined.  

    The TPS65381A-Q1 will only go to SAFE state on a mis-match on the NRES pin when DIS_NRES_MON bit is cleared to 0. When DIS_NRES_MON bit is set to 1, the NRES_ERR bit will set on a mismatch, but no state transition will occur.

    The customer has a lot of configuration options about what happens when the TPS65381A-Q1 transitions to SAFE state.  This is shown in the highlighted section Figure 5-16. Device Controller State Diagram below.

    In section 5.4.24 SAFE State, the details of using the NO_SAFE_TO, SAFE_LOCK_THR[3:0], SAFE_TO[2:0], and PWD_THR[3:0] configuration bits are outlined to get the device to have varying time it remains in SAFE before making a transition to RESET state, how many times the device will try to RESET, and if it then locks in SAFE state.  The default configuration of the device will be to lock in SAFE state, but the application software should configure these registers as the customer wants during the DIAGNOSTIC state when the application boots up.

    This note section has the details on it.

    If the device ends up locked in SAFE state, then the MCU must intentionally cause a RESET event such as intentionally sending bad watchdog events when WD_RST_EN is set to 1 or cause a power cycle event or path through STANDBY with a re-wake up signal.

    Hopefully this helps.

    Best Regards,

    Scott