I'd implemented a watchdog code on the S32K142 device where I checked & it's working absolutely fine. I developed with 300ms watchdog timeout & refreshing at 10ms rate.
Strangely, during the modifications in the later software, just adding accessing a variable in the main code is causing the reset and that too immediately 100ms after initializing, not at 300ms. I'm currently using S32DS version 2018.R1 & Build id: 180815 as shown below.
Also, this strange reset is not happening with the other system where the version is 2018.R1 & build id is 180326 as shown below.
I would like to know the probable reasons for the same.
Thanks in advance,
Thanks for the response.
- Yes, I checked the RCM_SRS and it confirms that the reset is happening because of the Watchdog.
-Also, My Optimization is none as well.
One thing I observed was I'm not enabling & disabling the interrupts during the refresh mechanism. If I do that the reset is not occurring.
Does the interrupts making the watchdog reset like this, kindly clarify the below points
Kindly clarify in this regard,
Thanks in advance,
accessing of variable or interrupts have nothing to do with watchdog. That seems to be just a side effect.
One idea - I would try to enable watchdog interrupt (INT bit in CS register) and disable watchdog in debug mode (DBG bit in CS). Once the interrupt is triggered, check the watchdog registers if you see anything unusual (CNT, TOVAL values...).
Thanks for the support & valuable suggestion.
I enabled the WDOG_EWM_IRQn both in the initialization and NVIC configuration. There is a reset because where the RCM-> SRS shows it is because of WDOG, but it did not cause any WDOG_EWM_IRQn though I kept a breakpoint at WDOG_EWM_IRQn.
Also, as I told the reset occurs after 100ms which may be the reason why the watch there is no WDOG_EWM_IRQn.
Then in such a case, what are the other causes for WDOG reset other than time/ TOVAL count. Also, during this time there is a refresh tick is happening every 10ms.
Looking forward to your valuable support.
Thanks & Regards,
after some deeper investigation, it seems it's really necessary to disable interrupts during refresh. You wrote:
"One thing I observed was I'm not enabling & disabling the interrupts during the refresh mechanism. If I do that the reset is not occurring."
But there's a note in the RM:
"Before starting the refresh sequence, disable the global
interrupts. Otherwise, an interrupt could effectively invalidate
the refresh sequence, if the interrupt occurs before the refresh
writes finish. After the sequence finishes, restore the global
interrupt control state."
And there's also code example:
To refresh the watchdog and reset the watchdog counter to zero, a refresh sequence is
required. The code snippet below shows an example for 32-bit write.
DisableInterrupts; // disable global interrupt
WDOG_CNT = 0xB480A602; // refresh watchdog
EnableInterrupts; // enable global interrupt
So, if this works, I would stick to this solution.
Thanks for the valuable information.
But, the reset is happening immediately after 100ms where the watchdog configuration is 300ms. Also, I can confirm there is a refresh at the 10ms rate. I would like to know whether the interrupts during the refresh mechanism reset the device else just ignores or invalidates the refresh mechanism.
Kindly confirm the same.
could you show me configuration of watchdog registers? And do you use 32bit write for refreshing? Or?
I'm not sure about the reason, I will ask apps/design team. But need more details...
Thanks for the response again.
My WatchDog Configuration is as shown below.
My refresh Configuration is as shown below.
Let me know where I'm going wrong. Looking forward for your valuable response.
Thanks in advance.