• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 105 subscribers
  • Views 263 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.

AM6548: Obtaining a reset reason after rti-wdt watchdog expiry

Jan Kiszka
Intellectual 410 points
Part Number: AM6548

On the AM65x platform, we are using the rti-wdt in combination with an R5 firmware (https://github.com/siemens/k3-rti-wdt) to monitor bootloader and Linux system. One of our users now requested a way to find out if a reset was caused by the watchdog expiry and started a discussion on a possible approach, see https://github.com/siemens/k3-rti-wdt/issues/1. Would defining some magic value for a magic RAM or SRAM location really by the only option we have? Or does the hardware offer something else?

  • 0
    TI__Guru*** 135298 points

    Hello Jan Kiszka,

    Thank you for the query.

    Let me review internally and update you.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Mastermind 23360 points

    Jan,

    Basically yes your SW on the R5 needs to store this info in some memory or flash. We discussed with the AM65x lead architect and here is a summary:

    There is no MMR in AM65x that automatically captures the reset cause. All the watchdog timer interrupts (other than the watchdog timer inside DMSC) are routed to error signaling module (ESM), either main ESM or wkup_ESM. Both ESMs can be configured to generate interrupts if any of the watchdog timer interrupt is asserted. The ESM interrupts are routed to R5 which can store or communicate the information. The watchdog timer inside DMSC will trigger full device cold reset if DMSC is hung.

      Pekka

  • 0 in reply to Pekka Varis
    Intellectual 410 points

    Thanks for checking this, Pekka.

    Ok, this raises the follow-up question how to make a software-based interface "official" so that both the R5 watchdog firmware and the drivers on the main CPU (kernel, U-Boot) can agree on the location and content of the magic field. Any suggestions on that would be welcome as well, but that may no longer be a topic for this forum as it affects upstream.

  • 0 in reply to Jan Kiszka
    TI__Guru*** 135298 points

    Hello Jan Kiszka

    Thank you for the note.

    I guess that would be a separate discussion and based on the need or use case may be a new thread could be created referencing this thread.

    I will close this thread for now and can be reponed based on inputs.

    Regards,

    Sreenivasa