• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 33 subscribers
  • Views 3398 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.

AWR1642: mmWave SDK 1.2: quesiton on Watchdog reset test mode

Chris Meng
Mastermind 35205 points
Part Number: AWR1642
Other Parts Discussed in Thread: IWR1642

Hi,

My customer tried Watchdog reset test mode with mmwave_sdk_01_02_00_05\packages\ti\drivers\watchdog\test\xwr16xx in CCS, but they found after the watchdog reset is issued, the JTAG is still connect and the test code exits normally. See below CCS console output.

[Cortex_R4_0] ********************************************************

Watchdog Unit Test                                      
Please select the type of test to execute:  
1. Watchdog reset test                      
2. Watchdog interrupt CPU test              
3. Watchdog DSP interrupt CPU test          
*******************************************************
> Enter your selection: Debug: Testing watchdog reset mode
Feature: Watchdog testing: Passed

We suppose that after watchdog reset, the MSS is warm reest and the code can't finish normally.

I also tried same test mode and got similar result. I checked SYSRSTCAUSE (0xFFFFE124) register value and it is 0000, instead of 1010 (Warm reset because of MSS Wdog).

My test steps are as below.

1. Connect R4F in CCS and reset R4F in CCS

2. Load xwr16xx_watchdog_mss.xer4f

3. Run

4. Stop and modify the value of testSelection to 1 in Expression Window (to select rest test mode)

5. Run again

Would you pls kindly help to advise if this test result is expected? If yes, how to verify the warm rest caused by watchdog reset of MSS is issued after running this test case?

  • 0
    TI__Guru*** 138349 points
    Hi,

    The value of the SYSRSTCAUSE does not seem correct.

    We need to check with testing team how this was tested

    thank you
    cesar
  • 0
    TI__Mastermind 21025 points

    Hi Chris,

    I repeated your test with the same result.  I then took a closer look at the test code, and it seems that it is only testing the driver APIs, not the watchdog functionality.  This was the case in several of the drivers for early SDK releases; I thought that they had all been updated.

    The watchdog test driver function watchdogTest() does briefly enable the reset if you enter 1 for testSelection, but then it toggles it on/off as it steps through the API calls.  It does not appear that the watchdog is actually performing a reset, so the value of zero in the register 0xFFFFE124 is correct.

      -dave

  • 0 in reply to db_woodall
    TI__Mastermind 35205 points
    Dave,

    I also checked the source of watchdogTest(). I think if reset mode is selected, the warm reset should be triggered after Watchdog_open() is called in watchdogTest(). Would you pls help to check again?

    To avoid other operations to disturb the watchdog reset, I commented some code of watchdogTest() API as below and tried again, but got same result with testSelection = 1.

    static int32_t watchdogTest()
    {
    ....
    /* Open the Watchdog driver */
    watchdogHandle = Watchdog_open(0, &watchdogParams);

    if (watchdogHandle == NULL)
    {
    System_printf ("Error: Watchdog Driver Open failed\n");
    return -1;
    }
    #if 0
    if (testSelection == WATCHDOG_APP_TEST_RESET)
    {
    Watchdog_clear(watchdogHandle);
    ....
    errCode = Watchdog_control (watchdogHandle, WATCHDOG_CMD_WINDOWSIZE, (void* )&windowSize);
    if (errCode < 0)
    {
    System_printf ("Error: Watchdog control Set Window size failed [Error code %d]\n", errCode);
    return -1;
    }
    #endif
    return 0;
    }

    Would you pls kindly advise how to implement the watchdog reset mode on mss and verify it?
  • 0 in reply to Chris Meng
    TI__Mastermind 35205 points
    Hi,

    Would you pls help again?
  • 0 in reply to Chris Meng
    TI__Guru*** 138349 points
    Chris,

    We will submit an SDK bug for this driver.

    If there is already a fix for this issue, we will let you know

    thank you
    Cesar
  • 0 in reply to Cesar
    TI__Mastermind 35205 points
    Cesar,

    Any update on this issue? Is there already a fix? If not, what's the plan to fix this issue?
  • 0 in reply to Chris Meng
    TI__Mastermind 22155 points
    Hello Chris,

    On warm reset, bootloader starts executing again and resets the SYSRSTCAUSE register and hence it cannot be used to get the last reset cause.
    The bootloader also stores the reset cause in a different register @ "0xFFFFE2FC (31:16)" .
    You can read this register address to get the last reset cause .

    Let me know if this resolves your issue.

    Thanks,
    Raghu
  • 0 in reply to Raghunandan Kamath
    TI__Mastermind 35205 points

    Raghu,

    I ran the demo again (org demo or demo with comment as previews post) and find the value of "0xFFFFE2FC (31:16)" is still 0x0.

    Would you pls help again?

    BTW, the warm reset of MSS will not reset the emulation module (JTAG), right?

  • 0 in reply to Chris Meng
    TI__Mastermind 22155 points
    Chris,

    I missed the point that my answer is valid only in the case of AWR1642 ES2.0 .

    For ES1.0, this is a known issue that the reset cause is not reflected in the reset cause register.

    -Raghu
  • 0 in reply to Raghunandan Kamath
    TI__Mastermind 35205 points

    Raghu,

    I tested on IWR1642 ES2.0 EVM and the value of 0xFFFFE2FC (31:16) changes to 0x99. What does 0x99 mean?

  • 0 in reply to Chris Meng
    TI__Expert 7215 points

    Chris,

    It means Reset cause is "System Out of NRESET"

    Regards,

    Kaushal

     

    Bits

    Field Name

    Description

    3:0

    SYS_RESET_CAUSE (current)

     

    Gives cause of system reset to the application

    1001

    System out of NRESET

    1010

    Warm reset because of MSS watchdog

    1100

    Warm reset because of software trigger SOFTSYSRESET

    1000

    External warm reset

    11:4

    MSS_RESET_CAUSE (current)

     

    Gives cause of MSS reset to the application

    0000 0010

    MSS only watchdog reset

    0000 0100

    MSS subsystem reset because of software trigger

    0000 1000

    Warm reset

    0000 1001

    System out of NRESET

    0001 0000

    STC reset

    0010 0000

    CR4 reset because of software trigger

    0100 0000

    CR4 reset because of writing to PRCR register in CR4 debug space

    1000 0000

    CR4 only watchdog reset

    15:12

    RESERVED

     

    19:16

    SYS_RESET_CAUSE (at Reset)

     

    Gives cause of system reset to the application

    1001

    System out of NRESET

    1010

    Warm reset because of MSS watchdog

    1100

    Warm reset because of software trigger SOFTSYSRESET

    1000

    External warm reset

    27:20

    MSS_RESET_CAUSE (at Reset)

     

    Gives cause of MSS reset to the application

    0000 0010

    MSS only watchdog reset

    0000 0100

    MSS subsystem reset because of software trigger

    0000 1000

    Warm reset

    0000 1001

    System out of NRESET

    0001 0000

    STC reset

    0010 0000

    CR4 reset because of software trigger

    0100 0000

    CR4 reset because of writing to PRCR register in CR4 debug space

    1000 0000

    CR4 only watchdog reset

    31:28

    RESERVED

     
  • 0 in reply to Kaushal Kukkar
    TI__Mastermind 35205 points
    Kaushal,

    Thanks for your reply.

    The original issue is that customer can't make the watchdog reset mode work, which should trigger a warm reset to MSS. Raghu said that if there is a warm reset, the bootloader will run and I need to check the value of "0xFFFFE2FC (31:16)" to find the last reset cause. Then I checked the value and with your help I knew it is system out of NRESET. It is not warm reset. So it verified that the reset mode test case in watchdog driver test code doesn't work.

    Would you pls help to check what is missed and how to make the watchdog reset mode work? Thanks.
  • 0 in reply to Chris Meng
    TI__Mastermind 22155 points
    Chris,

    Is this external watchdog reset ?

    -Raghu
  • 0 in reply to Raghunandan Kamath
    TI__Mastermind 35205 points

    Raghu,

    No. It is the watchdog timer inside AWR1642.

  • 0 in reply to Chris Meng
    TI__Mastermind 22155 points
    Issue is in the test application. Driver works fine.

    Replace the "Watchdog_clear(..)" in line 217 (func: watchdogTest() of file ti\drivers\watchdog\test\xwr16xx\main_mss.c) with a "while(1)" loop. When the core is spinning around in that while loop, watchdog will expire and trigger the warm reset. On warm reset, Bootloader starts executing again and resets the SYSRSTCAUSE register and hence it cannot be used to get the last reset cause. User can confirm the warm reset by checking the PC address - it will be the while(1) loop of the CCS debug application and not the watchdog test application.

    -Raghu