Watchdog on imx6Q timeout problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Watchdog on imx6Q timeout problem

Jump to solution
1,924 Views
andrewparlane
Contributor IV

Hi,

I'm having an issue with the watchdog timer. I wrote a linux app to open the watchdog device and set the timeout for 20s. It then polls the watchdog every 7s until you press any key, at which point it goes into a while(1) causing a watchdog as expected. The issue is the time before it watchdogs.

If I set the timeout to 20s and stop tickling it, the system reboots after 12s (since the last watchdog tickle).

If I set the timeout to the maximum of 128s, it times out 82s (since the last tickle).

Here is a trace with time stamps. Additionally I dump all wdt registers every time I tickle the watchdog.

[Fri May 01 16:49:21.788 2015] Setting watchdog timeout for 20

[Fri May 01 16:49:21.798 2015] tickling every 7s

[Fri May 01 16:49:21.798 2015] press enter to stop tickling the watchdog

[Fri May 01 16:49:21.798 2015] wcr 0x2735

[Fri May 01 16:49:21.798 2015] wsr  0xAAAA

[Fri May 01 16:49:21.798 2015] wrsr 0x0010

[Fri May 01 16:49:21.798 2015] wicr 0x0004

[Fri May 01 16:49:21.798 2015] wmcr 0x0000

[Fri May 01 16:49:28.809 2015] tickling

[Fri May 01 16:49:28.809 2015] wcr  0x2735

[Fri May 01 16:49:28.809 2015] wsr  0xAAAA

[Fri May 01 16:49:28.809 2015] wrsr 0x0010

[Fri May 01 16:49:28.809 2015] wicr 0x0004

[Fri May 01 16:49:28.819 2015] wmcr 0x0000

[Fri May 01 16:49:35.827 2015] tickling

[Fri May 01 16:49:35.827 2015] wcr  0x2735

[Fri May 01 16:49:35.827 2015] wsr  0xAAAA

[Fri May 01 16:49:35.827 2015] wrsr 0x0010

[Fri May 01 16:49:35.827 2015] wicr 0x0004

[Fri May 01 16:49:35.827 2015] wmcr 0x0000

[Fri May 01 16:49:42.839 2015] tickling

[Fri May 01 16:49:42.839 2015] wcr  0x2735

[Fri May 01 16:49:42.839 2015] wsr  0xAAAA

[Fri May 01 16:49:42.839 2015] wrsr 0x0010

[Fri May 01 16:49:42.839 2015] wicr 0x0004

[Fri May 01 16:49:42.839 2015] wmcr 0x0000

[Fri May 01 16:49:43.855 2015]

[Fri May 01 16:49:43.855 2015] not tickling, locking up now

[Fri May 01 16:49:55.772 2015]

[Fri May 01 16:49:55.772 2015]

[Fri May 01 16:49:55.772 2015] U-Boot 2014.04-07906-g2298031-dirty (Apr 24 2015 - 18:11:38)

...

Note the value in WCR: 0x2735. 0x27 translates to 20s. There reset occurs at 16:49:55.772 and the last tickle was at 16:49:43.839 which is a timeout of 12s.

Not really sure what's going on here, the registers are simple enough that there can't really be a mistake. All I can think of is that a clock is running at the wrong speed. However dumping the clock summarry in the debugfs shows ipg clk to be running at 66MHz which is the default.

The chip does not go into low power / sleep / ... it is also set at it's max frequency of 792MHz and uses the performance governor.

Any ideas?

Thanks,

Andy

Labels (2)
Tags (4)
0 Kudos
1 Solution
1,536 Views
andrewparlane
Contributor IV

Turns out this was due to not having an external 32.768KHz crystal. The WDT uses the internal ring oscillator instead, which according to the ERR007926, can run at up to twice as fast as it should.

View solution in original post

0 Kudos
3 Replies
1,537 Views
andrewparlane
Contributor IV

Turns out this was due to not having an external 32.768KHz crystal. The WDT uses the internal ring oscillator instead, which according to the ERR007926, can run at up to twice as fast as it should.

0 Kudos
1,536 Views
igorpadykov
NXP Employee
NXP Employee

Hi Andrew

one can check if access to wdog is 16 bit, refer to part of RM

Wdog.jpg

then one can test with wdog test, included in imx-test package (like imx-test-3.0.35-4.1.0/test/wdog)

Index of /buildsources/i/imx-test

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,536 Views
andrewparlane
Contributor IV

Hi Igor,

Yes I saw that, and checked. The linux driver uses __raw_writew() which turns into (*(volatile unsigned short *)(a) = (v))

So should be 16 bit access. Plus my dump, reads back and hence verifies the values. The extra leading 0s in my output trace is because I used %08X in my printk().

Thanks,

Andrew

0 Kudos