Problem with WatchDog Reset on 28335

Hello KK,

You should be able to determine if the reset was caused by the watchdog or some other source by checking the WDFLAG bit within the WDCR (Watchdog Control Register) following a reset. Refer to the TMS320x2833x, x2832x System Control and Interrupts Reference Guide for more information regarding the Watchdog Block. Below is the register description with important information such as the register being EALLOW protected and writing a 1 to the WDFLAG bit will clear the flag for future Watchdog reset detections.

The following (old) post has some sample code used to both detect and clear the Watchdog flag discussed above: http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/21643.aspx

Best Regards,

Mark-

The Watchdog system is fairly well described in chapter 5 of the System Control and Interrupts reference guide for the 2833x/2823x processor family.

The WDFLAG bit in the WDCR register indicates if a reset happened because of the watchdog or because of another reason.

The WDENINT in the SCSR register controls if you get a watchdog interrupt or a watchdog reset.

Hi,

Thanks for the post. My objective is to distinguish the resets caused by some external source or internal watch dog reset. As a primilinary step, without simulating any external reset code and after power up. I was checking the register WDCR if the flag WDFLAG is set or not. My observation is the WDKEY and WDCR registers are always set to 0x0004 and I am expecting WDCR register to 0x0084. 

Below is code snippet to perform the software reset. When it encounters this below code, I see that WDCNTR restarts from zero.

EALLOW;
SysCtrlRegs.WDCR   = 0x0094; 
EDIS;

Could anyone help me or any ideas?

Thanks,

KK

Hello KK,

Further analysis of the Reference Guide I linked to in my initial response shows that reading the WDKEY register will return the value of the WDCR register according to the  WDKEY Field Descriptions in Table 29.  This is why they are both returning the same value.  The reason WDCR register is set to 0x0004 is most likely due to your WDT initialization code setting the Watchdog pre-scale (WDPS) to WDCLK = OSCCLK/512/8 (100).

When you are setting WDCR = 0x0094 you are not writing 101 to the WDCHK bits which causes a reset or watchdog interrupt if the watchdog is enabled most likely resulting the WDCNTR register restarting from 0.  If you have the watchdog enabled and configured to perform a reset, then a device reset should occur after the WDCR set.  Can you check that ~XRS is high when the ~WDRST signal has a rising edge? The paragraph following WDCR Field Descriptions explains this in further detail.

Best Regards,

Mark-

Hello Mark,

Thanks for the note. After going through some series of test, watchdog code is seems to work which means watchdog is able to reset the processor and set a flag. Due to hardware limitation, I was not able to check the XRS pin.  When I changed my watchdog initilization  to WDCLK = OSCCLK/512/64 and SCSR. So that watchdog is set to reset mode only. Upon power up the WDCR register sets to 0x00C0 indicating that WDFLAG is set upon power up. When it encouterers the WD init function, the WDCR changes to 0x0087 due to initlization. From my app code, when I try to clear the WDFLAG just before performing a reset (WDCR = 0x0094) the WD flag NEVER clears and it stays at 0x0080.

Question:

a. Why watchdog is working when WDCLK is changed to above register setting? ( As per document, Watchdog device reset must be longer in duration then the watchdog pulse). 30000000/512/64 = 0.109msec. ( Init WDCLK) and app code WD clock is 30000000/512/8 = 0.13msec.

b. Should this clearing WDFLAG be performed just after power up functions and before WD init?

EALLOW;

if(SysCtrlRegs.WDCR & 0x0080)  // Check the flag.
{
            SysCtrlRegs.WDCR |= 0x0080;    // clear watchdog flag
}

 SysCtrlRegs.WDCR  = 0x0094;

EDIS;

Am I missing something? Please assist.

Thanks,

KK