| Author |
Topic |
|
|
akidder
1519 Posts |
 Posted - 18 Dec 2002 : 17:57:29
|
WatchdogTimerTest.exe (StrongARM and XScale Watchdog Timers for CE)
We've generally advocated that since CE is so stable, you can implement a "monitor" thread to which other threads must report. You can then restart the system if any one of them fails to report. However, we do recognize that it's possible to monopolize CE to the exclusion of other threads.
Using the Watchdog Timer
The StrongARM includes a conventional watchdog timer that will reboot the processor if the timer isn't re-armed within the timeout period you set. We have implemented access to this timer and offer it with source code in the example below.
The timeout period can be set to microsecond resolution, but we offer it in a function that allows you to configure it between one second and nineteen minutes in one-second increments. See the comments in the readme file for details about how to use the functions and the included CE sample application. Of course, you can modify the code to suit your needs.
Theory of Operation
The watchdog timer is a 32-bit register (OSMR3) linked to the operating system count register (OSCR), an up-counter that runs continuously at 3.6864 MHz on current ADS StrongARM and XScale systems. When the OS count register matches the value in the watchdog register, the system resets. The counter rolls over to zero about every 19.4 minutes (1165 seconds).
Once the watchdog timer function is enabled, the application must regularly change the value in the watchdog timer register, reading the current value of the OS timer, adding a certain number of counts to it, and writing it back to the watchdog timer register. Perform 32-bit modulo arithmetic to ensure that you generate the correct value for the watchdog register (if you use 32-bit unsigned integer data types, it should work fine).
Important Note (Bitsy)
The watchdog may not work with the Bitsy under some circumstances (see Topic 199 for details). This issue does not apply to the Bitsy Plus, BitsyX and other ADS products.
| Key APIs Used WRITE_REGISTER_ULONG
READ_REGISTER_ULONG
VirtualAlloc
VirtualCopy
VirtualFree
SetTimer
KillTimer
Lines of Code: 251
|
Source Download
For XScale: ZIP, 14kB (EXE and source)
For StrongARM: ZIP, 317k (Rev 3 - March 4, 04)
Known issue: Data types for registers should be unsigned integers (DWORD or ULONG). E.g.
void WatchDog::Pet()
...
LONG DWORD oscr;
LONG DWORD osmr3;
Edited March 4, 04 (ctacke) - added eVC 4.0 project files, compiled XScale binary and optional WatchDog class files
Edited March 31, 02 (ctacke) - added key APIs and LOC
Edited by akidder 19-Apr-2005: Add Theory of Operation section and known issue about incorrect data type in source sample.
|
|
|
ctacke
877 Posts |
Posted - 28 May 2003 : 16:40:07
|
Update for XScale Processor Devices
WatchdogTimerTest.exe is written for the StrongARM processor, but can be easily modified for the XScale processor with these steps:
- In the source code, open sa1110.h
- Find the following line:
#define OST_PHYSICAL_BASE 0x90000000
- Replace it with this:
#define OST_PHYSICAL_BASE 0x40A00000
- Recompile
- Run
Note: The above project is an eVC 3.0 project. Since it uses MFC, and since the MFC library names changed from CE 3.0 to CE 4.x, you will have to create a new project with eVC 4.0 to generate a binary compatible with CE 4.x.
|
 |
|
|
akidder
1519 Posts |
Posted - 02 Oct 2003 : 18:05:41
|
#detect_watchdog
Q. How can I tell if a watchdog reset occurred?
The RSCR register records the reset cause on SA-1110 and PXA255 processors. The boot code has to read it to determine how to boot the system. Unfortunately, the boot code has to reset the register after it reads it, so you can't determine the boot cause that way.
One way that you could differentiate between cold boots and warm resets would be to put a "magic" number in the Power Manager Scratch Pad register (PSPR, 0x40F00008). The PSPR is used by the OS during sleep/wake cycles, but is otherwise unused. PSPR is only cleared when power is disconnected and is otherwise left intact through resets.
If that magic number were present in the PSPR when your application started, it would indicate that your application had been interrupted by a software, watchdog, or hardware button reset.
Important: This solution will not work for the PXA255. Unlike the SA-1110, the PXA255 clears the PSPR register when it resets the board. It is possible to store contents of RCSR elsewhere. Contact Eurotech for a quote if such a solution is required for your application.
Edited by akidder 26-Aug-2009: Updated with details about PXA255. |
|
|
|
ctacke
877 Posts |
Posted - 04 Mar 2004 : 13:59:52
|
Update
We modified the download as follows:
- Added project files for eVC 4.0
- Added an XScale-compiled binary
- Added WatchDog class source files
The new WatchDog class is simply another way to use the same functionality, but intended for developers who prefer C++. It can be used as follows:
WatchDog *wd = new WatchDog(10000); // create a 10-second timeout watchdog
// ...
while(working)
{
wd.Pet(); // reset the watchdog timer
DoWork();
}
// ...
// Calling delete() frees memory allocated by the WatchDog
// class. However, note that the hardware WatchDog timer itself
// cannot be disabled once you have enabled it
delete wd;
|
|
|
|
|
akidder
1519 Posts |
Posted - 22 Nov 2004 : 19:10:06
|
#TriggerWatchdog_XScale
TriggerWatchdog (XScale)
By request, we've put together a short app that triggers the watchdog timer on the XScale CPU. You can use it in place of restart.exe in the event you want to force a hardware reset.
rev 3, ZIP 14kB (EXE and source) |
|
|
|
akidder
1519 Posts |
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
eVC - Watchdog Timer Functions
Forum Locked
Topic Locked
Send Topic to a Friend
Printer Friendly