• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 1100 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.

AM6442: Register that indicates a Watchdog timeout reset has occurred

Jason Reeder
Genius 10440 points

Part Number: AM6442

My customer is looking for a register to read at power on to determine if the most recent reset was caused by a Watchdog timeout.

I can see the CTRLMMR_RST_SRC (0x43018178) and CTRLMMR_MCU_RST_SRC (0x04518178) registers in the TRM but there is no bit that indicates a Watchdog reset.

Is there another register I should be checking?

  • 0
    TI__Guru 54738 points

    Hello Jason,

    I am looking at TRM for any registers that have watchdog reset statuses, and please allow me one or two days to get back to you.

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Guru 54738 points

    Hello Jason,

    There are no direct registers to monitor the watchdog's expiration time status.

    If you need to monitor the watchdog's expiration time status, then you have to monitor ESM registers.

    The watchdog design is different in AM64X, and it does not support auto-resetting the SOC when the watchdog expires.

    So, in AM64X, when the watchdog expires, an event is routed to the NMI interrupt and ESM module.

    The user can reset the SOC from the ESM module only.

    In my view, if you get an event from the NMI or ESM module, you don't need to monitor the Watchdog Timer expiration status.

    Please let me know what the use case is here, and are you using the ESM module to reset the device?

     

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Genius 10440 points

    S.Anil,

    The customer would like to know during the boot process why/how the device was reset. Specifically, if the most recent recent was caused by a timeout of the WD timer.

    I can see the reset source registers (CTRLMMR_RST_SRC and CTRLMMR_MCU_RST_SRC) that are used for this purpose, but what I'm now unclear on, is which bit would be set after a WD timeout given the MCU ESM is handling it. Does this mean that the SAFETY_ERROR bit (bit 31) should be set? Or does the ESM cause a different type of reset?

    Jason

  • +1 in reply to Jason Reeder
    TI__Guru 54738 points

    Hello Jason,

    Typically, the expectation is to self-reset the SOC when WDT has expired, but this is currently not supported by AM64X and AM62X devices.


    How to solve above problem?

    1. Configure ESM to route the RTI interrupts to generate ESM interrupts. All ESM interrupts are routed to all the processors. We can use ISR from any of the processor to generate

    SW trigger SOC reset through the CTRL_MMR_MCU. 

    2. Configure ESM to route the RTI interrupts to error output, which is one of the warm reset sources.

    Actually, AM64X devices do not support triggering SOC reset after watch dog  expiration; due to this, there are no specific registers to monitor wathc dog  expiration status.

    So, if the reset is due to the DMSC watchdog, then it will be indicated in the DMSC cold_out_rst or warm_out_rst status.

    The other watchdog timeouts are only possible through ESM. If the reset is through ESM, then it will be indicated in mcu_esm_err_rst or

    main_esm_err_rst. - > This status can be monitored only in method 2

    (configure ESM to route the RTI interrupts to error output, which is one of the warm reset sources).

    For method 1, there is no possibility to monitor the watchdog Reset sttaus since in this method the user can use MMR registers to make SOC reset.

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Genius 10440 points

    S.Anil,

    I webex'ed with the customer today and they confirmed that bits 30 and 31 are being set after the WD timeout on AM64x using Linux. So it appears that option #2 is being used with the Linux WD example.

    Jason

  • 0 in reply to Jason Reeder
    TI__Guru 54738 points
    Jason Reeder said:
    I webex'ed with the customer today and they confirmed that bits 30 and 31 are being set after the WD timeout on AM64x using Linux. So it appears that option #2 is being used with the Linux WD example.

    Hello Jason,

    As of now, I am aware that method 2 is not available in either MCU+SDK or Processor SDK.

    I would like  to know  how user method 2 code is implemented ?

    Is it possible to share method 2 code only? since I need to confirm whether the user is using method 1 or method 2.

    If they are using method 2, then it makes sense to monitor the 30 and 31-bit status.

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Genius 10440 points

    S.Anil,

    The watchdog test procedure being used is described here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1270510/am6442-watchdog-timer-issue-on-sr2-0-silicon/4811949#4811949

    I confirmed with the customer that bits 30 and 31 are set after this process occurs.

    Are you saying that you think option 1 is being used in the watchdog example? How are bits 30 and 31 being set in my case?

    Jason

  • +1 in reply to Jason Reeder
    TI__Guru 54738 points

    Hello Jason,

    I looked at the above code, and it looks like they implemented it in the second method, and they are controlling the MCU_ESM_ERROR_RST_EN_Z bit, and I

    have not seen controlling SOC reset with the help of any MMR Registers after expired Watch Dog Time.

    So, monitoring 30 bits and 31 bits is the proper method.

    I will confirm with Hong again for clarification after watchdog expiration whether SOC is reset with the help of CTRL_MMR_Registers or not.

    Regards,

    S.Anil.