Adding task to dynamic software watchdog in the MDM 8215 / MDM 9215

Adding your task to dog monitoring is OPTIONAL unless you have a specific requirement otherwise.
Registering your task with dog will have a NEGATIVE impact on power. Do not assume you have a requirement to register with dog.

1.. You are not required to be monitored by dog.
2.. If you are not being monitored by dog, then there is no need to call dog_report().
3.. Excessive use of dog monitoring negatively impacts power
4.. Dog services were originally implemented to meet IS95 requirements are to turn off radio transmitter when handset function is impaired.
5.. Setting autodog for a task allows the task to be blocked indefinitely without a dog timeout resulting. This can be set for instance by calling rex_autodog_enable().
Below are the API-s to use add task in dog table.




dog_report_type dog_register

(

rex_tcb_type *p_tcb,

dog_timeout_enum_type timeout_flag,

dog_deadlockcheck_type deadlockcheck_flag /* Not yet supported */

)



DESCRIPTION

Dynamic way for tasks to register for dog services.

A replacement for hard coded timeouts in dog.c for CMI compliance.



PARAMETERS

timeout_flag: Starvation detection threshhold

DOG_FAST_TIMEOUT - RESTRICTED to select critical tasks

DOG_DEFAULT_TIMEOUT - Normal tasks

deadlockcheck_flag: Currently ignored. Select either value

DOG_DEADLKCHK_ENABLE - enables deadlock checks

DOG_DEADLKCHK_DISABLE - check for deadlocks disabled



RETURN VALUE

dog_report_type - handle/ID used for dog interface





uint32 dog_get_report_period(dog_report_type dog_report_id) DESCRIPTION Function to return the number of msec between expected calls to dog_report(). This will be less than the dog timeout period by a safety margin. RETURN VALUE 0 - DO NOT REPORT TO DOG. >0 - Report to dog every x msec.void dog_deregister(dog_report_type dog_report_id) DESCRIPTION Dynamic way for tasks to de-register for dog services for CMI compliance.void dog_report(dog_report_type report) DESCRIPTION Report to the watchdog task, so that it can tell that the monitored task is still functioning properly.User can refer to any <taskname>.c file for the example of the usage of above mentioned API-s.



You do NOT need to edit dog.h/dog.c on targets with dynamic dog enabled (listed below)



Key take away points:

1) When DOG_DYNAMIC_API is defined in dog.h, then the dynamic dog is available and should be used. It MUST be used for any new tasks, as changes to dog.c and dog.h will no longer be supported to add new tasks.

2) If the return value to dog_get_report_period() is ZERO, then do not start a timer as you should not report to dog directly. In the future a newer version of dog ("dog 2.0") will monitor tasks without many of them directly reporting to dog.



All configuration is stored in variable dog_state_table, which is an array where each index represents one task. The notable attributes are:

a.. timeout - the timeout value (currently in seconds) of the task
b.. count - amount of seconds left the task has to respond
c.. is_blocked - boolean that is set to 1/true when the task is not currently monitored by dog
For Example Please refer to the KB#00022776 Example of adding task to dynamic software watchdog