• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 404 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Can device get stuck in SAFE state?

Marcus Coxon
Prodigy 250 points
Part Number: TPS65381A-Q1
Other Parts Discussed in Thread: TMS570LS1224

Ref: data sheet SLVSDJ1A –JULY 2016–REVISED MAY 2017, section 5.4.25 SAFE State; I quote:

NO_SAFE_TO = 1 (Default)
• While DEV_ERR_CNT[3:0] < (SAFE_LOCK_THR[3:0] + 1) the time delay for the SAFE
state time-out is programmed by the SAFE_TO[2:0] bit. The delay is calculated by
[(SAFE_TO[2:0] × 2) + 1] × 22 ms.
• The device remains locked in the SAFE state when DEV_ERR_CNT[3:0] ≥
SAFE_LOCK_THR[3:0] + 1.

Given the default reg values, is it possible to get stuck in SAFE state?  A particular scenario I have in mind is as follows:

  1. Power-up occurs.
  2. The TPS LBIST (not to be confused with the TMS related selftest) fails.
  3. Device transitions to SAFE state; DEV_ERR_CNT[3:0] increments to 1.
  4. SAFE_LOCK_THR[3:0] remains at default (=0).
  5. Device evaluates "DEV_ERR_CNT[3:0] ≥ SAFE_LOCK_THR[3:0] + 1" as "1  ≥ 1 = TRUE"
  6. Device remains in SAFE state.
  7. nRES not asserted; consequently MPU (TMS570LS1224) continues the restart.

Given that our design is reliant upon a subsequent transition to either RESET or STANDBY states (ENDRV not used), what is the recommended action that should be taken by the MPU code, bearing in mind that it is perhaps questionable that the MPU should do anything given that its power supply has just failed?

Marcus

  • 0
    Prodigy 250 points

    Damn: error in last posting: I had meant to ref section 5.4.24, not 5.4.25!

    Marcus

  • 0 in reply to Marcus Coxon
    TI__Genius 12735 points

    Hi Marcus,

    Assuming this is for an automotive application, I think the important question in this case is what is the expected need for your system to do from a functional safety stand point if the PMIC is failing an LBIST run. If LBIST_ERR is set on the PMIC (which is set in the case of an LBIST failure) then the device will immediately transition from DIAGNOSTIC state to SAFE state until LBIST is run without an error.

    I would highly recommend utilizing ENDRV in your system so it is clear if the PMIC is functioning properly and you would not require the PMIC to go to STANDBY state when there is a device error that would normally send the device to SAFE state. By utilizing ENDRV you allow SAFE state to actually be a SAFE state for your system which will help with any issue that would send the device to SAFE and not only during the LBIST failure scenario.

    If you cannot use ENDRV in your system for some reason then you would need to devise a way to allow the MCU to pull IGN and/or CANWU low (and clearing the IGN_PWRL bit and/or sending the WR_CAN_STBY command as needed) when an LBIST failure is detected by reading the LBIST_ERR bit in SAFETY_STAT_3. This may work for an LBIST issue but if there are any other issues that make communication impossible or if the MCU is not longer functioning then using a method like this will not work, which is why I would recommend using ENDRV.

    Best regards,

    Layne J

  • 0 in reply to Layne J
    Prodigy 250 points

    Hi Layne J, thanks for your update re ENDRV.  Perhaps my original posting was a little incomplete; when I stated that ENDRV isn't used in the system, I was referring to the controlled hardware, but what I omitted to say is that this signal is fed back to the TMS570 where it can be monitored via MIBSPIS5NCS[0].  Going back to my original scenario, with the TPS device in SAFE state and NRES not asserted, the code could detect this condition via MIBSPI5NCS[0]; under these circumstances, can the startup code take any actions by programming the TPS registers, to recover?

    Marcus

  • 0 in reply to Marcus Coxon
    TI__Genius 12735 points

    Hi Marcus,

    When the device is in SAFE state and you are trying to exit without the ability to pull NRES low then I would recommend forcing a watchdog failure (WD_FAIL_CNT=7+1) as long as WD_RST_EN=1. This will cause a transition to RESET state and then to DIAGNOSTIC following the normal flow. If there is an LBIST failure as originally discussed, BIST will be run again and if still failing the device will go to SAFE state again, otherwise it will stay in DIGANOSTIC state following the normal behavior.

    There is not any way to ignore an LBIST or ABIST error that I am aware of on these devices.

    Best regards,

    Layne J

  • 0 in reply to Layne J
    Prodigy 250 points

    Hi Layne J, I'm a bit confused.  RE:

    Layne J said:
    When the device is in RESET state and you are trying to exit

    followed by:

    Layne J said:
    This will cause a transition to RESET state and then

    Was the first ref to "RESET State" a typo mistake, especially as the 2nd ref speaks of a "transition to" the RESET state?

    I'm assuming that the first ref to "RESET state", should have been to "SAFE state"; is this correct?

    RE:

    Layne J said:
    would recommend forcing a watchdog failure

    If I'm correct in the above assumption, then you appear to be suggesting that the code can use the WD to get from SAFE to RESET state; how can this be best done?  Back again to the original scenario, TPS in SAFE following an LBIST failure, immediately after reset,  WD_FAIL_CNT should contain its init count of 5 and consequently, 3 increments of the counter would be req'ed to force a reset; is there an easy way to achieve this?

    Marcus

  • 0 in reply to Marcus Coxon
    TI__Genius 12735 points

    Hi Marcus,

    My apologies, you are correct in that the first statement should have been SAFE state, I have updated my original post to reflect this. 

    In the case that the device experiences an LBIST failure and transitions to SAFE state on the first power up and the MCU was not able to set any of the registers that can only be modified in DIAGNOSTIC state the device will be stuck in SAFE state until it is transitioned to STANDBY state and then re-enabled. I will also highlight that it is unlikely to be stuck in SAFE state unless there is something causing ABIST or LBIST to fail or the MCU does not begin to communicate with the PMIC before the DIAGNOSTIC state timeout finishes. 

    If the MCU is able to configure WD_RST_EN=1 on the initial startup, intentionally sending wrong answers or not sending any watchdog answers will cause the WD_FAIL_CTN to increment, but this will not have any impact if WD_RST_EN has not be configured by the MCU while in DIAGNOSTIC state.

    Best regards,

    Layne J

  • 0 in reply to Layne J
    Prodigy 250 points

    Hi Layne J, RE: 

    Layne J said:
    If the MCU is able to configure WD_RST_EN=1 on the initial startup, intentionally sending wrong answers

    What you have just said re feeding the chip wrong answers, was something I was considering whilst writing my previous posting, but this idea had floundered on the rocks that are the "BIG IF": 

    Layne J said:
    If the MCU is able to configure WD_RST_EN=1

    as there are a number of scenarios in which this cannot be achieved.  Thankfully, the hardware design is to be updated to use ENDRV signal to drive the hardware into a safe state.