J784S4XEVM: Watchdog reset is not happening for J784S4 R5F

Hi Jim,

What is the application and use case where you see this issue?

Are you specifically using MCU_RTI0 in your application?

Thanks,

Neehar

Yes, I am using MCU_RTI0. It does not need any application. From register condition I put there, WD is enabled with reset action, and RTI_WDSTATUS indication watchdog violation is there; the R5F should reset with those condition. If you disable watchdog, manually configure those registers as I showed here, then enable the watchdog, the reset should happen.  Clock for MCU_RTI0 is 32K clock 

Hi Jim,

If you are not using this in your application, what is your use case for this? What are you using MCU_RTI0 for? Is it for benchmarking or some other use case?

Jim Zhang said:

Clock for MCU_RTI0 is 32K clock 

Did you get this value from checking CTRLMMR_MCU_RTI0_CLKSEL[2-0] CLK_SEL and value of '11'?

Thanks,

Neehar

I am using this in my application. I use MCU_RTI0 as watchdog. Application needs to strobe watchdog every 2s otherwise, watchdog will reset the system.

Yes, I verified that CTRLMMR_MCU_RTI0_CLKSEL[2-0] CLK_SEL value  is  '11

WD_STATUS indicates that watchdog violations had happened, but system is not reset

Hi Jim,

Can you test with MCU_RTI1 as watchdog and see if you can replicate the same issue?

Does this issue happen at a specific time in your application? Such as during boot? During boot up, DMSC will use MCU_RTI0 watchdog timer, as specified below, to perform WDT reset if the TIFS image is not loaded within the allotted 3 minutes. 

Thanks,

Neehar

Yes, I tested with MCU_RTI1 and result is same. Even MCU_RTI0 is used during startup, I reconfigured the watchdog in my app, and watchdog related registers are changed to my configuration, it should overwrite the configuration from startup. So the watchdog should work as it is configured now.

The issue is: even WD_STATUS indicates that watchdog violations happened, but watchdog action was not happening. The watchdog behaviour does not meet the action that currently configured for this watchdog.  The module does not work the way it is configured too. Do we miss any kind of internal link (something similar to that we need turn on channel gate to be able to freeze timer count when enabling timer freeze bit) ?

Hi Jim,

Jim Zhang said:

Even MCU_RTI0 is used during startup, I reconfigured the watchdog in my app, and watchdog related registers are changed to my configuration, it should overwrite the configuration from startup

Could you please provide the code where you configure the watchdog?

I do understand based on the register values that there should be a reset occur.

Jim Zhang said:

Do we miss any kind of internal link (something similar to that we need turn on channel gate to be able to freeze timer count when enabling timer freeze bit) ?

I am double checking with colleagues on this as well.

Thanks,

Neehar

any feedback from your colleagues on the reset action ?

another question, when a watchdog reset is happening, does it reset the whole system ? or it only resets the r5f core ? 

If it reset the whole system including main cores, this is not what we want. How could we configure to only reset r5f core ?

There are simple test apps under this folder below in sdk, what is the step to build this test app ?  I can modify the app here to enable watchdog and test.  

ti-processor-sdk-rtos-j784s4-evm-10_01_00_04/pdk_j784s4_10_01_00_25/packages/ti/csl/test/core-r5 

One issue I found is: I can not change the RTI clock from mcu_ctrl_mmr_cfg0 registers. My program can not configure the clock, and I tried changeing the clock source from debugger like below, it does not allow me to write.  Any special steps to make  mcu_ctrl_mmr_cfg0 registers writable ?  Is address translation needed to configure the clock? I noticed that TI example is also doing direct register writing

Hi Jim,

Jim Zhang said:

another question, when a watchdog reset is happening, does it reset the whole system ? or it only resets the r5f core ? 

If it reset the whole system including main cores, this is not what we want. How could we configure to only reset r5f core ?

Let me double check on this and get back to you on this.

Jim Zhang said:

There are simple test apps under this folder below in sdk, what is the step to build this test app ?  I can modify the app here to enable watchdog and test.  

ti-processor-sdk-rtos-j784s4-evm-10_01_00_04/pdk_j784s4_10_01_00_25/packages/ti/csl/test/core-r5 

You may be able to build with 'csl_core_r5_baremetal_test_app'. Note not all the tests are validated and supported. You can see the tests here.

Jim Zhang said:

Any special steps to make  mcu_ctrl_mmr_cfg0 registers writable ?

Can you confirm whether you are unlocking the KICK protection registers when accessing this register space? Please take a look at the following snippets from the TRM:

Thanks,

Neehar

Now I am able to change the clock to 32K, thank you!

Before app execution:

clk is not set,

mcu rti0 is not configured

After running my program:

clock is configured to 32K

mcu_rti0 is configured, and for sure in my program there is a watchdog violation but the action is not happening.

It came to my question yesterday:

The reset action is going to reset the whole system, or only the r5f mcu domain ? or only mcu_r5f_0 core only ?

This action should be taken care by HW, but why HW did not take action?

Here is the process to reproduce the issue:

1: load any SDK demo app (the app does not use mcu_rti0) by debugger, and execute the demo app, break the execution

2: reconfigure mcu_rti0 clock to 32K manually from debugger by following steps:

    a:  write 0x68ef3490 to address 0x40F09008

     b: write 0xD172BC5A to address 0x40F0900c

     c: write 0x3 to address 0x40F08180

     d: write 0x0 to  address 0x40F09008

3: configure the mcu_rti0 watchdog from debugger manually

    a: write 0x13 to address 0x40600094

    b: write 0xff to address 0x40600098 to clear the watchdog status

    c: write 0xA98559DA 0x40600090 to start the watchdog

run the program again, and see if the reset action is triggered by watchdog or not

you can use debugger scripts to write those registers, it will be more straightforward then code

Now I am able to change the clock to 32K, thank you!

Before app execution:

clk is not set,

mcu rti0 is not configured

After running my program:

clock is configured to 32K

mcu_rti0 is configured, and for sure in my program there is a watchdog violation but the action is not happening.

It came to my question yesterday:

The reset action is going to reset the whole system, or only the r5f mcu domain ? or only mcu_r5f_0 core only ?

This action should be taken care by HW, but why HW did not take action?

Here is the process to reproduce the issue:

1: load any SDK demo app (the app does not use mcu_rti0) by debugger, and execute the demo app, break the execution

2: reconfigure mcu_rti0 clock to 32K manually from debugger by following steps:

    a:  write 0x68ef3490 to address 0x40F09008

     b: write 0xD172BC5A to address 0x40F0900c

     c: write 0x3 to address 0x40F08180

     d: write 0x0 to  address 0x40F09008

3: configure the mcu_rti0 watchdog from debugger manually

    a: write 0x13 to address 0x40600094

    b: write 0xff to address 0x40600098 to clear the watchdog status

    c: write 0xA98559DA 0x40600090 to start the watchdog

run the program again, and see if the reset action is triggered by watchdog or not

you can use debugger scripts to write those registers, it will be more straightforward then code

From J721E reigisters description, watchdog reset -s not supported ? Can you confirm if watchdog reset is suppoted by J784S4 ?