TMS320F28379D: Watchdog reset reason with Watchdog disabled

Luis,

     Can you please display the RESC register in CCS? I would like to see what value the register holds.

Luis,

     I tried this on silicon and I do see WDRSn bit set after a power-up but not the POR bit. Let me check with our Design team. It will take a few days to provide a response.

Hi Hareesh,

This is what I read from the RESC register. 

Notice that the WDRSn pin is set while the watchdog is disabled (In both CPUs)

For the moment this is the most important thing, to identify how the WDRSn can be triggered if we are not using the watchdog.

Thanks for you help

 Luis,

          Let us divide this post into two categories:

1. WDRSn bit is getting set when WD is actually disabled. Note that I also saw this bit being set after power-up. As part of the initialization, do you clear this bit?
2. POR bit not getting set. I am working with our Design team to understand this.

Hi Luis,

Can you please check if the RESC has the WDRSn bit already set in the initial time when you just connected the device?

If yes, can you please write a 1 to the RESCCLR register to clear the RESC bit for WDRSn.

The WDRSn bit will be cleared only by a POR or if we write a value 1 to the CLR register. 

And try running your application and see if still the MCU is resetting due to WDRSn.

Thanks

Aswin

Hi Aswin,

Yes, I can confirm that the bit is always low when starting the application and it is only set to high after the reset is detected. There is always a power cycle between each test we execute, so the WDRSn bit is being constantly cleared by a POR.

Thanks

Luis

Hi Luis,

From the chart it is evident that these are the possibilities of having a WDRSn ( section 3.9 Watchdog timer in TRM)

1) Watchdog will be enabled by default so while disabling if you give wrong key it will give WDRSn.

2) If the counter has expired.

3) Any attempt to service the watchdog when WDCNTR is less than WDWCR triggers a watchdog interrupt or reset. (please have a look at the section 3.9.2 Minimum window check)

Is it possible to debug further on the issue, like can you step in and see which part is causing the reset?

So that we can have more clarity.

Thanks

Aswin

Hi Aswin,

The watchdog is disabled during initialization and we never service it, clear it, or do anything related to it. This issue is random and occurs roughly 5% of the power cycles. I think if we had an issue with the watchdog, we would be seeing this problem more often.

Also, a reminder that the WDDIS bit is set to 1, so after reviewing the Figure 3-13, I think the watchdog should never be triggered 

Here is the file where the watchdog is disabled

Thanks

Luis Nuñez said:

This issue is random and occurs roughly 5% of the power cycles.

The above makes the debug challenging. This is one of our best-selling devices and we have shipped millions till date. This is not to say that no issue will ever be found in this device. Just that an issue with a 5% failure rate would have come to our attention by now.

1. During initialization, I presume you clear the WDRS bit in the RESC register. Do you read back that register to make sure your clearing went through?
2. In how many boards is this problem seen?
3. Does the code work fine in standalone mode i.e. without the JTAG connector connected?
4. Assuming it is practical/feasible to run the application in a TI-designed board like ControlCARD/LaunchPad, is the problem seen in those boards?
5. Is the - XRS pin being driven by an open-drain device?
6. Would you be willing to share the schematics with us privately?

Luis,

     It appears WD is getting re-enabled in your application. One reason it can happen is when ITRAP is asserted. The ITRAP ISR (in Boot-ROM) enables the WD. You need to investigate why ITRAP is happening in your system. One reason is illegal op-code. It is likely that your system is impacted by noise, which likely corrupts the Program Counter, which cause the device to execute garbage resulting in ITRAP. It is also possible some RAM location is corrupted leading to a similar scenario. Noise is more likely since this happens only 5% of the time.

Luis Nuñez said:

I noticed that the SysCtl_getResetCause function never returns 1 (POR bit enabled).

Turns out that Boot-ROM clears this bit. I will file a ticket to add this clarification in the TRM.

Hi Hareesh,

That's good to know! Noise has been one of our main suspicions, but we have not been able to capture it when the fault happens. We have monitored the power supplies with no luck. Is it possible that the MCU might be affected by noise from other sources? The clock, the gpios, etc?

Thanks for your help