Watchdog In CE?

Jul 12, 2007 at 3:13 AM
Edited Jul 12, 2007 at 3:41 AM
I have found this where it describes on how to use a watchdog. Earlier in the post they stated that the OEM can produce a API which is much easier to consume? I looked in the Managed Gumstix API but couldn't find anything. So is there a API to use the watchdog?

If not can I build a watchdog using eVC (guess will have to learn) that can access the IOCTLHALREBOOT and hopefully reboot the gumstix?
Jul 12, 2007 at 4:16 AM
I have done this before on other projects. The Gumstix BSP actually does a watchdog reset when the OALIoCtlHalReboot is called. follow the OEMReset function to see how it works. With the Managed Gumstix API you can get at any and all native PXA255 registers through C# code therefor you can access the watchdog register also.
Jul 12, 2007 at 8:01 PM
From everywhere I have read so far...I am going to try to use eVC with a Gumstix SDK being exported from PB 5. By doing thins I will hope to expose IOCTLHALRESET.

2. Through the Gumstix API will probably much easier to access and shortly here will look through the PXA255 developers manual to see if I can invoke a reset using registers (never have done this before).

If I get something working (hopfeully I will) I will post it on here.
Jul 14, 2007 at 6:10 AM
I tried to build the Gumstix SDK and had no luck. I think a lot of the problem was the lack of knowledge I had with PB to begin with. So I turned to the registers.

Here is what I came up with to try to reset the gumstix:

NOTE: All the registers have been converted to a decimal form

uint uintOSCR;

//enable OWER (watchdog enable register)
IO.Register.Write((uint)1084227608, (uint)1);

//Get OSCR
uintOSCR = IO.Register.Read((uint)1084227600);

//ADD Value to OSCR (OSCR + (Seconds * 1,857,205)
uintOSCR = uintOSCR + 18572050; //10 seconds

//write NEW OSCR value to OSMR3 and wait for the reset
IO.Register.Write((uint)1084227584, (uint)uintOSCR);

I can get the OIER Bit 3 to return a 1 (Match between OSMR3 and OS timer asserts OSSRM3 but when I check OSSR Bit 3 it is set to 0, so I am wondering if I am not doing something write in my code. I have tried to debug it to the best of my knowledge. What is really wierd is sometimes it works like 5 minutes later and sometimes it never trips to reset it.

Everything to explain is in the PXA255 developers manual 4-34 through 4-42 has a detailed explanation on how the watchdog works and all the registers.
Jul 15, 2007 at 12:53 AM
One thing, you don't want to enable untill AFTER you load the new timeout value. Also, you probably can not "debug" (or single step) this routine as the timer will probably rollover before you enable it.
Jul 27, 2007 at 3:58 PM
Well I have done more experiments and still not having any luck. I read somewhere on the internet the watchdog can restart as fast a 9 ms to 19 minutes. My gumstix always restarts before 19 minutes but no faster than 10.

I was hoping to achieve less than a minute before the watchdog restarts the gumstix. Any help appreciated.
Jul 27, 2007 at 4:28 PM
Also I want to add that there is something strange going on while trying to write back the new value (current clock count + the 3,686,400 * Seconds) into the OS Timer Match Register (OSMR3).

Let us say the Timer Count is at 221184000. (1 minute runtime)
I take 221184000 and add 20 seconds (20s * 3,686,400) = 73728000. So I kick the dog every 5 seconds and add 20 seconds to the watchdog.
I then write the new value with the added time into the OSMR3.

The odd part is CE locks up while trying to write the new value in OSMR3. The value is then written after the OS Timer Count is past my new value. So in short my Match Register is always behind the current Timer Count so it never gets matched.

It's like setting a alarm off for a time that has already passed. Then to add to it the watchdog does reset the gumstix but when it feels like it.

And ideas?