TPS65224-Q1: Watchdog Trigger Mode

Hi Samuli

    We feed the watchdog per 40ms, it work properly.

    Another question, we start to feed watchdog(escape long window)  at 1s later after MCU start up. In this case, after watchdog reset AM62A, AM62A will power up properly sometimes.

    If we start to feed watchdog(escape long window) once MCU start up. In this case, after watchdog reset AM62A, AM62A power up properly every time.

    What is the cause of this issue? The long window time interval is 8s, window1 time interval is 11ms, window2 time interval is 44ms.

Best Regards.

Xianti

Hi Xianti,

This sounds more like a question to the processor team. I will move the thread to the processor board.

BR,

Samuli

Hello Xianti,

Please give us additional background about your system.

1) Are you using a TI EVM, or a custom board?

2) How is the watchdog getting fed?

3) I do not understand your working case and your not working case. I assume you did not mean to say "escape long window" for both cases?

Please reword this information: "we start to feed watchdog(escape long window)  at 1s later after MCU start up. In this case, after watchdog reset AM62A, AM62A will power up properly sometimes... If we start to feed watchdog(escape long window) once MCU start up. In this case, after watchdog reset AM62A, AM62A power up properly every time."

Regards,

Nick

Hello Nick

    Thanks for your reply.

Nick Saulnier said:

1) Are you using a TI EVM, or a custom board?

    Custom board.

Nick Saulnier said:

2) How is the watchdog getting fed?

    Watchdog works at Trigger mode. AM62A generated the trigger pulse at MCU_GPIO0_23, this pin connected with GPIO2 of PMIC.

Nick Saulnier said:

3) I do not understand your working case and your not working case. I assume you did not mean to say "escape long window" for both cases?

   The long window interval time was set as 8s.

    Working case:  After initial the watchdog, MCU generated the trigger pulse immediately, then MCU fed watchdog per 40ms. In this case, after watchdog reset AM62A, AM62A power up properly every time.

    Not working case: After the watchdog is initialized for 1 second, the MCU generates a trigger pulse,  then MCU generated the trigger pulse per 40ms. In this case, after watchdog reset AM62A, AM62A will power up properly sometimes.

BR.

Xianti

Hello Xianti,

1) Which core of the AM62Ax is driving the trigger pulse? What software driver are you using, and are you doing any configuration of that driver?

2) When are you initializing the watchdog (I assume at some point during or after the AM62Ax boots?)

Regards,

Nick

Hello Nick

     We use R5F (MCU Channel) to generate trigger pulse.

     After MCU start up every time, we disable and enable Watchdog, then this issue has been solved.

    So the cause may be the long window interval time is about the time MCU started up, so long window time out sometimes when MCU warm boot up.

BR.

Xianti

Hello Xianti,

I see.

This is my first time working with this particular PMIC - could you point me to the documentation that discusses the long window interval? I have requested access to the full datasheet, not sure if that is where the long window is discussed or if I have to refer to a different document.

If the watchdog is timing out before the MCU domain R5F core is up and running, there are multiple potential things that could be tweaked.

1) Adjust the long window interval to be longer - I am not sure if this is even possible, but that is one option

2) Optimize the AM62Ax bootflow

For example, if you are using the standard SPL boot flow found in the AM62Ax Linux SDK, then Linux boots first, and then the Linux remoteproc driver initializes the MCU R5F, and THEN the MCU R5F could begin feeding the watchdog.

You could work on optimizing Linux boot to happen quicker, or move to initializing the MCU R5F during uboot instead of after Linux boots, or switch to a different bootflow (e.g., use SBL to initialize the MCU R5F first BEFORE Linux boots, and then boot Linux).

For more information about boot flows and different methods to initialize non-Linux cores, you can reference the AM62Ax academy, multicore module, Booting & Disabling Processor cores:
https://dev.ti.com/tirex/explore/node?node=A__Ada-WjvmUg3JmB109NavGA__AM62A-ACADEMY__WeZ9SsL__LATEST

Regards,

Nick

Hello Nick

    The documentation we are referring is <TPS65224-Q1_SLVSGG7_Full_Datasheet_Dec2023_TIConfidentialNDARestrictions.pdf>.

BR.

Xianti

Hello Xianti,

Ok, it does look like the long window interval can be modified to be different from 8 seconds. From the datasheet:

6.3.10.2 Watchdog Start-Up and Configuration
When the device releases the nRSTOUT pin and if configuration bit WD_EN=1 , the watchdog starts with 
the Long Window. This Long Window has a time-out interval (tLONG_WINDOW) with a default value set in bits 
WD_LONGWIN[7:0].
The WD_LONGWIN[7:0] bits configure the length of the Long Window time-out as follows:
• 0x00: 80 ms
• 0x01 - 0x40: 125 ms to 8 sec, in 125-ms steps
• 0x41 - 0xFF: 12 sec to 772 sec, in 4-sec steps

I assume it is probably easiest to see if this is a "time that it takes to boot" issue by keeping everything the same on the processor side, and adjusting the long window interval by either modifying the long window timeout to be longer, or setting the WD_PWRHOLD bit to disable the Long Window time-out until the processor is ready to begin feeding the watchdog. If your issue goes away with a longer window interval, then we can move forward with the options I mentioned in my previous response: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1390125/tps65224-q1-watchdog-trigger-mode/5325538#5325538

I am sending your thread back to the PMIC team to comment on what would be the easiest way to do the next debug step.

Regards,

Nick

Hi Xianti,

please try what Nick suggested and increase the long window interval by writing to the WD_LONGWIN register. Please note that in order to write to this register you have to be in long window and use the I2C2_ID and if used also the I2C2 bus. 

regards,

Niko