Cause of iMX6Q/D Watchdog timer resetting the system?

[gmmo]

Hi, I am working on an embedded system that uses on the main board and iMX6Q/D and runs Android Jelly beans, more precisely: Linux version 3.0.35, Jelly Beans

It is an embedded system and "out of the blue" the system completely resets itself. By looking at the uboot reason of reset we are able to see the code 0x0011, which inside the kernel says "WDOG"

void disp_boot_reason(void)
...
...

case 0x0010:
case 0x0011:
printk("WDOG");
break;
....

The system has been in development for a long time, it started back in 2013. So things are quite old, but we can't changed the hardware or OS at this stage.

From the iMX 6Dual/6Quad Reference manual I read:

"The Watchdog Timer (WDOG) protects against system failures by providing a method by
which to escape from unexpected events or programming errors."

I see no traces of software failure either from the linux kernel logs or the android adb shell logs. I do see that the watch dog is set to be server every 60s

10-13 22:53:05.750 E/kernel  ( 2403): <6>imx2-wdt imx2-wdt.0: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=1)

Here are my questions?

1. It is a software or hardware fault? I am assuming it is hardware since our software is running fine.

2. What do the manual mean by "unexpected events"? Hardware fault?

3. Is there a way to know, from the hardware perspective what is the root cause of the watchdog not being served by the kernel? We are suspecting our display, but not totally sure.

4. When there is a hardware fault, can I add some logs to the kernel to help pin point what hardware component is making the watchdog timer not kick in?

5. known hardware bugs regarding the iMX watchdog timer? Can it be served and reset the processor anyway?

[gmmo]

I was looking at this thread more carefully and have another question.

https://community.nxp.com/thread/457871#comment-935193 

it says:

"Increase VDD_ARM_IN and VDD_SOC_IN voltage to 1.275V
..according to the values of the datasheet in kernel-imx/arch/arm/boot/dts/imx6q.dtsi for LDO enabled mode."

Our android version is JellyBeans more specifically:

Linux version 3.0.35  (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #7 SMP PREEMPT Wed Oct 18 10:22:25 PDT 2017

but when I did a search of the file, I don't find it.

/arch/arm/boot/dts/imx6q.dtsi

Any of you know where I can set this voltage on JellyBeans? Is there another way to setup these voltages? This is what I see under our folder:

thank you!

[Yuri]

Hello,

  It makes sense to check memory.

https://community.nxp.com/docs/DOC-105652 

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[michaelguntli]

The typical watchdog reset occurs because the ARM was not able to pet the watchdog in the given time frame.

• What's the error behavior when the watchdog kicks in? (maybe record it with a camera)
• What's the CPU load of your system?
• Do you have GPU intensive tasks? Could be a bus "deadlock":
  https://community.nxp.com/thread/457871#comment-935193 
• Have you verified the stability of the voltage supply (VDD_ARM_IN and VDD_SOC_IN)?
  https://community.nxp.com/thread/457871#comment-949758 

[gmmo]

Michael, the system is a medical device and we disabled the hardware acceleration completely. There are no GPU intensive tasks going on. It is just a simple Android activity running a simple test overnight that uses few hardware components: heater and a mechanical pump. Yet, when we come back to check the device, usually after 2 days, it is back to the home screen of our application, and from the UBOOT log we see that a hardware reset has happened because of the watchdog timer. Here more questions if you happen to know:

1. It looks like from the manual it is done through an interrupt service. So who registers this interrupt?

3. I am software engineer (not hardware) Is there some chip pin accessible from outside that we can probe so that we know the root cause of the reset?

thank you!