Specifications

AVIDdirector-M2M™ Technical Reference Guide
February 5, 2009 ©AVIDwireless 2004-2009 All Rights Reserved Page 10 of 55
resets. If the WatchDogTimer thread doesn't call "SNAP.feedWatchdog()" then a hardware reset of the
AVIDirector is performed without a logging notification - this means that the WatchDogTimer cannot run and
the system will spontaneously reboot itself.
The WatchDogTimer maintains a list (Java Hashtable) of threads it is monitoring. Each thread must implement
the Java interface "WatchDogMonitoredClass" to identify that it will implement the WatchDogTimer contract.
Each period the WDT checks for the last time the WatchDogMonitoredClass thread checked in (by calling
"resetWatchDogTimer) to verify that it is greater than the contracted period set by
"registerWatchDogMonitoredItem". If so, then the thread is deemed to have timed out and the WatchDogTimer
calls the AVIDirectorApp.fatalError method, which writes an entry to the system Log (and turns on writing the
Log to the file system if this is not enabled), writes a special entry to the file "/LastFatalError.log" and performs a
hardware reset by calling "Ish.reboot". AVIDirectorApp.fatalError(int errorCode, String errorMessage) is used in
multiple places whenever an object has detected a fatal error (e.g. a Radio class cannot establish a PPP
connection 5 times in a row) and the Object wants to log a fatal error and reset the system.
A WatchDogMonitoredClass can permanently remove itself from the WDT's list by calling
"watchDogTimer.removeMonitoredItem(WatchDogMonitoredClass this)". It will be no longer checked when it
does this and it must call registerWatchDogMonitoredItem(WatchDogMonitoredClass this,String name, int
period) to register itself again. This is done if a thread is terminating and if it is run again then a new thread
instance is created. If a thread is running continuously in a loop but will be idle for an extended period of time, it
can temporarily turn off the WatchDog time from monitoring it by calling
"stopMonitoringItem(WatchDogMonitoredClass this)". The WDT will then ignore checking this class after this is
called. The WatchDogMonitoredClass thread needs to call "startMonitoringItem(WatchDogMonitoredClass this)"
to return to being checked by the WDT. There is a version of this call with the time period (in milliseconds) that
can be called if the thread wants to modify the time it is checked.
In M2MApp the items that are monitored are:
1. AVIDirectorApp - This is the main application thread for M2MApp. It handles the startup, normal operation
and shutdown of the system. When AVIDirectorApp starts one of the first things it does is to create the
WatchDogTimer instance with an internal polling time of 120 seconds. During the initial loading of classes, due
to the time to read from the serial Flash memory chip and uncompress the Jar files, extra time is allowed for the
WatchDog timer. Once the AVIDirectorApp has completed initializing all the IODevices, Communicators and
Radios, it sets the WatchDogTimer to a 60 second polling time.
In AVIDirectorApp it performs a single continues loop consisting of:
a. Check for messages to send to the M2MXML Portal. If a messages exists it will use the Communicator
to send the messages. It adds the message to the Communicator's outbound queue and waits for an
acknowledgement from the M2MXML portal. If a message is sent out then the TXMessage timer is reset.
b. Check for incoming messages from the M2MXML portal. If it is waiting for an acknowledgement to a
send message that is check and if present, the sent message is marked as being sent correctly and the
next messages will be sent the next time the loop reaches (a). If it is not an acknowledgement but an
error message (e.g. the device is not registered with the M2MXML portal, this is logged and the message
is discarded. Otherwise the packet is parsed to see if it contains a valid M2MXML message, and if so, it is
then parsed and passed to the appropriate IODevice or M2Mlet. If a message is received, valid or not, the
RXMessage timer is reset.
c. Check if the available memory is low and perform a garbage collection.
If more than time specified by the M2MApp.ini M2MXML.MAX_NOCOMM_TIME parameter goes past with out a
TX or RX message, then a fatal error is reported. This time is longest you will expect your application to be
without communication to the M2MXML platform.
If the AVIDirectorApp doesn't check in with the WatchDogTimer every 60 seconds then the WDT will flag this
set.