• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 706 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TDA4VM: Does K3CONF have support under qnx operating system?

TDA4VM: How watchdog reset and VTM warm reset state cooperate to ensure that the system does not enter an infinite loop

TANG PENG
Prodigy 30 points
Part Number: TDA4VM

Hi  expert

       on ourself board， the watchdog（PTPS65941212RWERQ1 pmic function）reset the TDA4 by PORz；

       We set the reset time of the watchdog to be about 1s; when the system heats up, if there is no watchdog reset, the tda4 will restart after the temperature returns to normal. However, after the system heats to death, because the dog is not fed in time, the watchdog will PORz TDA4. After reset, the system will start immediately. At this time, if the temperature is too high, TDA4 will enter a hot reset again, resulting in an infinite loop.

       Without the watchdog, the TDA4 can be reset from warm, but the system cannot turn off the watchdog

      my question is：

      1，If the current watchdog reset pin does not change, how to solve this infinite loop problem at the software level

      2，How to solve the relationship between watchdog and warm reset

      3，How to ensure that it does not enter this infinite loop

  • 0
    TI__Guru** 110651 points

    Hi,

    Please be aware of the Votlage and Thermal Manager (VTM) described in TRM Section 5.2.2.1.5 Voltage and Thermal Manager, provides the control, status as well as interrupt and event generation related to integrated temperature sensors and thermal events programed by the user. 

    Each temperature sensor can be thresholded individually.  The comparator outputs can be individually enabled to generate an interrupt for

    • Max temp (thermal reset),
    • Overtemp (for SW activity throttling),
    • Undertemp (for SW hysteresis). 

    The interrupts sources are logically OR’d so SW needs to determine individual source during ISR.

    If aforementioned use case has been understood correctly, the undertemp (LT_TH0_INT) for the sensor of concern, could be programmed to prevent S/W from starting until the lower threshold is reached.  See, Section 5.2.2.1.5.3.2 VTM Temperature Driver Alerts and Interrupts.

    Regards,

    kb

  • 0 in reply to KB
    Prodigy 30 points
    KB said:
    could be programmed to prevent S/W from starting until the lower threshold is reached

    Yes, if there is an external hardware watchdog, the TDA4 will wait until the lower threshold is reached
    However, due to the existence of an external hardware watchdog, the watchdog will use PORz to restart TDA4, TDA4 will exit the hot state and restart immediately

  • 0 in reply to TANG PENG
    TI__Guru** 110651 points

    Is below a correct summary.

    The system is at step (4-5) of below sequence from TRM, and a PORz is occurring due to an external watchdog timeout?   I will check with team on recommendations for external watchdog in this scenario.

    Note that when OverTemp was detected on the way to Maximum Temperature, S/W could have taken some action.

    Could you please comment on why the temperature is not reducing as expected in step (5), which then becomes a 1 (s) PORz?  Is the 1 (s) continuous PORz keeping temperatures high, or are external factors keeping temperatures high?

    Thanks,

    kb

    5.2.2.1.5.3.7.1 VTM Max Temperature Outrange Alert.

  • 0 in reply to KB
    Prodigy 30 points
    KB said:
    The system is at step (4-5) of below sequence from TRM, and a PORz is occurring due to an external watchdog timeout

    yes

    KB said:
    Could you please comment on why the temperature is not reducing as expected in step (5), which then becomes a 1 (s) PORz?

    watchdog timeout

  • 0 in reply to TANG PENG
    TI__Guru** 110651 points

    Thanks,

    Regarding, could you please add some detail:

    Intent of question was to understand why temperature is not reducing.  Is the high temperature maintained a result of the device restarting continuously, or a result of external factors, such a thermal testing in a temperature chamber.   

    Regards,

    kb

  • 0 in reply to KB
    Prodigy 30 points
    KB said:
    Intent of question was to understand why temperature is not reducing.  Is the high temperature maintained a result of the device restarting continuously, or a result of external factors, such a thermal testing in a temperature chambe

    a thermal testing in a temperature chamber

  • +1 in reply to TANG PENG
    TI__Guru** 110651 points

    Hi,

    Thanks for response.  The root cause of the overall scenario is that the external temperature is too high, and needs to be reduced.

    To avoid the reset loop, which is being driven by the external watchdog, S/W mitigation would likely need to be added.  Suggestions on this below, are provided to continue the conversation.   This has not been tested on the TI side.

    1.0: Modify boot flow to check undertemp, disable/backoff external watchdog, until temperature is reduced

    0. As early as possible in boot flow, check if any temperature sensor is above "undertemp".

    If any sensor above undertemp

    1. Optional checks on an SRAM status bit, or reset reason could be added to logic here.
    2. Halt boot flow
    3. Disable, or backoff, or feed, external watchdog
      1. Disable would remove reset loop, as watchdog no longer active, until temperature is reduced
      2. Backoff, would, change watchdog delay, increasing the period of the resets, until temperature is reduced
      3. Feed, keep feeding the external watchdog, while waiting for temperature to reduce.
    4. Wait for undertemp to clear
    5. When undertemp clears,
    6. Re-enable / adjust external watchdog
    7. Clear optional SRAM status bit.
    8. Trigger PORZ, or continue boot flow.

    If below under temp

    1. Continue boot flow

     

    2.0: Make initial TSHUT less likely to occur

    1. Thermal monitoring detects an OverTemp, prior to TSHUT threshold being reached.
    2. Optionally store a status in SRAM, for checking during boot.
    3. Disable major pieces of S/W, functional, clocks to reduce temperature

    If temperature is reduced

    1. Detect that over temp has cleared
    2. Clear the optional SRAM status
    3. Re-enable, the disabled functionality and clocks

    If MAX temp is exceeded, and TSHUT occurs

    1. Warm reset occurs
    2. PORz from watch dog timeout occurs
    3. Goto “1.0” above.

    Regards,

    kb

  • 0 in reply to KB
    Prodigy 30 points

    thank you very much