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.

TMS320F28375D: Watchdog reset CPU1 and CPU2?

Part Number: TMS320F28375D


Hi Experts,

I am asking for my customer here. Customer want to use CPU1.WDRS and CPU2.WDRS to reset CPU1 & CPU2.

We tested the below code, it's a bit off what's described in the TRM manual below Table.

#define WD_PRESCALER_1            0
#define WATCHDOG_PRESCALER        WD_PRESCALER_1
 
 
#define WatchDog_enable(WD_PRESCALER)                                           \
          EALLOW;                                                               \
          WdRegs.WDKEY.bit.WDKEY = 0x0055;                                           \
          WdRegs.WDKEY.bit.WDKEY = 0x00AA;                                           \
          WdRegs.WDCR.all = WD_CHECK|WD_PRESCALER;                             \
          EDIS;
 
#define WatchDog_restart()                                                      \
          EALLOW;                                                               \
          WdRegs.WDKEY.bit.WDKEY = 0x0055;                                           \
          WdRegs.WDKEY.bit.WDKEY = 0x00AA;                                           \
          EDIS;
 
 
    #define WATCHDOG_RESTART()
                WatchDog_restart()
 
    #define WATCHDOG_ENABLE()                                                   \
                WatchDog_enable(WATCHDOG_PRESCALER)
 
 
void main(void)
{
 
WATCHDOG_ENABLE();
 
While(1)
{
     WATCHDOG_RESTART();
……
}
}

Test results:

CPU1 WD reset    ->   CPU1 + CPU2 both reset

CPU2 WD reset    ->   CPU1 + CPU2 both reset

But from the below table, CPU1.WDRS can reset both CPU1 and CPU2, but CPU2.WDRS only can reset CPU1.

Could you help look into this issue above? Why CPU2.WDRS can reset both CPU1 and CPU2? Thanks.

  • But from the below table, CPU1.WDRS can reset both CPU1 and CPU2, but CPU2.WDRS only can reset CPU1.

    In the above line, I think you wanted to say "CPU2.WDRS only can reset CPU2", not CPU1. Anyway, your understanding is correct that CPU2.WDRS should not reset CPU1.

    The code snippet you provided does not reset the WD; it only resets the WD counter to zero.

  • Hi Hareesh,

    Right. But Customer testing found that CPU2's watchdog can reset CPU1. We're not sure where the setting problem is, or is there an error in the TRM description? Thanks.

  • As mentioned before, the code snippet you provided does not reset the WD; it only resets the WD counter to zero. From the TRM:

    Each CPU has a watchdog timer that can optionally trigger a reset that lasts for 512 INTOSC1 cycles. CPU1's watchdog reset (CPU1.WDRS) produces an XRS. CPU2 watchdog reset (CPU2.WDRS) produces a CPU2.SYSRS and triggers an NMI on CPU1.

    So, CPU2.WDRS only asserts an NMI on CPU1. 

    Please have customer write a simple testcase: Disable WD on CPU1. Enable WD on CPU2 and let it overrun. Monitor -XRS pin. Please send the testcase along with the scope capture. Please do this without the debugger connected. 

  • Hi Hareesh,

    Got it. I am asking customer to do this step now. Will update to you later.

  • Posting the below for Shaoxing, since the thread had locked

    Please help look into the below created e2e thread issue. Recently customer tested waveform following Disable WD on CPU1. Enable WD on CPU2 and let it overrun. Monitor -XRS pin. But we find that XRSn both have

     

    1. CPU1 watchdog disable; CPU2 watchdog enable, and enter the while(1) infinite loop after 10s. (Blue is XRSn Pin)

    The XRS pin will be pulled low every 10.0277s or so (cyclically pulled low), and the low level lasts for about 70us.

     

     

    1. CPU2 watchdog disable; CPU1 watchdog enable, and enter the while(1) infinite loop after 10s.

    The XRS pin will be pulled low every 10.0288s or so, and the low level will last for about 70us.

     

    So we doubt that why the same result when different conditions? BTW, CPU2.WDRS will not output low signal to XRSn Pin. Could you help look into this case? Or guide us Why is CPU2 watchdog behavior inconsistent with the TRM description? Thanks.

  • Shaoxing,

        A reset that is asserted every 10s cannot be from the watchdog. If OSCCLK =10MHz, the WD timeout frequency is around 13.1ms. Please have customer examine the RESC register.