Tuning the watchdog timer - correct place?

[Hugh Frater]

Where does one go to tune the watchdog timer? Is it a kernel-recompilation-required thing, or can it be done through uBoot?

Or.... should I just use my PRU code to tune the watchdog control register when it boots? This would be the easiest option for me, if someone can point me at the correct area if the AM335XTRM? I had a look in there and couldn't find the correct registers.

I'd like it to run about 10 seconds if possible for my application.

[Hugh Frater]

Update: page 4492 of the TRM details the watchdog timer. I'll probably use the PRU to configure the registers unless there is an easier way...

[Mark Lazarewicz]

I'd ask the question are these register's accessable from the PRU my experience is dated and I'm not a Linux guy but most OS protect Access to certain registers I briefly looked at TRM the WDOG is enabled by default probably during boot. To set it or change the clock source you disable it which I doubt Linux would like from PRU side  but maybe I'm wrong. I'd look at the interconnect block diagram to see if PRU has access to the registers. Google am335x watchdog c code I see discussion about Kernel configuration. Typically on non Linux ARM side project TI provided quite a bit of example code for customer boot code options that's where I always start but that code isn't always in the public  domain and in your case isn't relavent after Linux takes over you may have to let ARM Linux side handle it. I'd look at PRU register memory map unless someone in here has done it from PRU. 

Good luck

Sent from Yahoo Mail on Android

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2d6c30bf-484e-49e6-ab9d-582535f60a84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hugh Frater]

My experience of working directly with the i2c and eqep parts of the silicon from within the PRU suggest that register access to the watchdog peripheral would be both easy and reliable. It's simply a #define and you can then access the register contents directly from within the PRU. 

I will write some test code to reconfigure the watchdog and report back.

On Tuesday, 4 June 2019 02:02:37 UTC+1, lazarman wrote:

I'd ask the question are these register's accessable from the PRU my experience is dated and I'm not a Linux guy but most OS protect Access to certain registers I briefly looked at TRM the WDOG is enabled by default probably during boot. To set it or change the clock source you disable it which I doubt Linux would like from PRU side  but maybe I'm wrong. I'd look at the interconnect block diagram to see if PRU has access to the registers. Google am335x watchdog c code I see discussion about Kernel configuration. Typically on non Linux ARM side project TI provided quite a bit of example code for customer boot code options that's where I always start but that code isn't always in the public  domain and in your case isn't relavent after Linux takes over you may have to let ARM Linux side handle it. I'd look at PRU register memory map unless someone in here has done it from PRU. 

Good luck

Sent from Yahoo Mail on Android

On Mon, Jun 3, 2019 at 7:07 AM, Hugh Frater

<hugh....@gmail.com> wrote:

Where does one go to tune the watchdog timer? Is it a kernel-recompilation-required thing, or can it be done through uBoot?

Or.... should I just use my PRU code to tune the watchdog control register when it boots? This would be the easiest option for me, if someone can point me at the correct area if the AM335XTRM? I had a look in there and couldn't find the correct registers.

I'd like it to run about 10 seconds if possible for my application.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagl...@googlegroups.com.

[Hugh Frater]

An update - I haven't got round to testing new PRU code. However, this:

Setting and getting the timeout:
	For some drivers it is possible to modify the watchdog timeout on the
	fly with the SETTIMEOUT ioctl, those drivers have the WDIOF_SETTIMEOUT
	flag set in their option field. The argument is an integer
	representing the timeout in seconds. The driver returns the real
	timeout used in the same variable, and this timeout might differ from
	the requested one due to limitation of the hardware.

From here: https://github.com/philenotfound/beagleboneblack-kernel/blob/master/Documentation/watchdog/watchdog-api.txt

Looks relevant. Does anyone know if the Watchdog driver supports on the fly timeout adjustment?

[Hugh Frater]

Update: The kernel watchdog driver support tuning the timout through ioctl calls. A quick and dirty bit of C code:

int main()

{

    int fd = open("/dev/watchdog", O_WRONLY);

    int timeout = 5;

    ioctl(fd, WDIOC_SETTIMEOUT, &timeout);

    printf("Setting timeout to %d seconds\n", timeout);

    close(fd);

    return 0;

}

Will tune the watchdog. I use node.js' child_process to call the above code (when compiled, obviously), if my node.js app crashes then the BBB will reboot. Perfect

On Monday, 3 June 2019 13:07:49 UTC+1, Hugh Frater wrote:

[Mark Lazarewicz]

Did you verify the time out changed? 

If so how?

Sent from Yahoo Mail on Android

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ab8ea583-ab9a-4017-a89f-6bd8127eaf47%40googlegroups.com.

[Hugh Frater]

Yep, I did verify that. You need to use the child_process.execSync() function to call the tuning binary from Node.js because you must wait for the tuning to complete before opening the watchdog device from within your Node.js application. I know, using synchronous functions inside an asynchronous environment like Node.js is bad practice, blah blah blah - It works, it's good enough for me. 

Verification of the timeout change is done by looking at the timeout and timeleft entries in:

/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0

For example, on first boot:

debian@beaglebone:/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0$ cat timeout
60

Then I start my Node.js application that in turn calls the watchdog tuning binary then sets up a 1 second write to the watchdog device:

debian@beaglebone:/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0$ cat timeout
5

debian@beaglebone:/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0$ cat timeleft
4

If I Ctrl-C my Node.js application (simulating a lockup/it crashes etc) then I can watch the timeout value count down and the system reboots.

I hope that helps...

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ovGQSAXqwBE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/952566089.2906417.1560876023480%40mail.yahoo.com.