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

AM2432: Question regarding watchdog timer reset expiration time and leveraging ESM reset status register for watchdog reset counter

Hong Zhang
Intellectual 752 points
Part Number: AM2432

Hello, 

Here are two questions that have been discussed with TI over the call. I just create this thread to track the status. 

  1. To understand whether it is possible to leverage ESM reset status register to indicate watchdog reset has occurred.  With several SW warm reset use case, need to figure out a way to identify watchdog reset to increase watchdog reset counter.
  2. To understand whether it is feasible to set the r5f core0’s watchdog timer reset expiration time to be 3/5 minutes for SBL bootloader, and re-configures the same watchdog timer with a longer expiration time for appimage. The current appimage uses 70 minutes expiration time, which would need to increase a counter 5 times. TI would explore the possibility to eliminate the use of the counter.

Thanks,

Hong 

  • 0
    TI__Genius 15435 points

    Hi Hong,

    I am working on this thread, allow me some time to get back.

  • 0
    TI__Genius 15435 points

    Hi Hong

    Hong Zhang said:
    To understand whether it is possible to leverage ESM reset status register

    Can I know what status register are you referring to here? I am not able to find any register that holds the reset cause in the ESM registers list.

    Hong Zhang said:
    The current appimage uses 70 minutes expiration time

    This 70 minutes expiration time is incorrect, to achieve such higher timeouts we need to have a very slow clock input to the WDG, unfortunately we do not have such lower clock source in Am243x. Also, can I know how was this calculation of 70 minutes arrived at please?

    Thanks

  • 0 in reply to Kowshik Gudimetla
    Intellectual 752 points

    Hello Kowshik,

    Thanks for your help.


    The ESM reset register is the ESM_ERRORz that I referred above.

    For the watchdog timer, the max timeout is about 17 minutes based on 32k clock.  We plan to use larger value than 17 minutes, such as 70 minutes. That is what I referred to. I think based on your reply there is no slower clock source available. 

    Thanks,

    Hong

  • 0 in reply to Hong Zhang
    TI__Genius 15435 points
    Hong Zhang said:
    The ESM reset register is the ESM_ERRORz that I referred above.

    Are you referring to any other register addendum document apart from the TRM manual? I only see the below registers available

    Thanks,
    G Kowshik

  • 0 in reply to Kowshik Gudimetla
    Intellectual 752 points

    Hello,

    This is the register I am referring to:
     

    Thanks,

    Hong

  • 0 in reply to Hong Zhang
    TI__Genius 15435 points

    Hi Hong,

    The ESM_ErrorZ register seems to be of not bigger use because it is a register that can be used to assert a reset but not read back and perform actions. The register you're looking for is RST_SRC register as shown below. This can be read back and appropriate actions can be taken.

  • 0 in reply to Hong Zhang
    TI__Mastermind 20412 points

    Hey Hong,

    So the way I visualize utilizing the ESM Reset to clearly differentiate the WDT expiry reset is shown below:

    1) WDT Expire EVT1 -> Interrupt CPU -> increment count variable -> reset WDT.

    2) Step 1 repeats until the count value is reached for required extended expiry time.

    3) WDT Expire EVTn -> Interrupt CPU -> Trigger MAIN ESM Error Interrupt -> Trigger ESM_ERRORz reset

    4) At this point, after reset has complete, the RST_SRC register can be read. If bit[30] (MAIN_ESM_ERROR) of this register is set then it can be assumed that the reset was due to the extended WDT expiration. 

    Note that this assumes the MAIN ESM is not used to trigger an ESM_ERRORz reset from any other error/interrupt sources.

    Best Regards,

    Zackary Fleenor