Documentation: how to use auto monitor feature to keep the chip alive #2543
Conversation
| This command resets the watchdog timer ("ping", "pet the dog", "feed the dog"). | ||
|
|
||
| Using the Auto-monitor feature to keep the chip alive |
There was a problem hiding this comment.
I am confused by this. Is this named correctly? A HW watchdog needs to be "reset" if not when it times out it is "triggered".
So what is Auto-monitor? Is the generating the keep-alive? Then it is not a monitor,
There was a problem hiding this comment.
Hey @davids5
What name do you refer to?
The Auto-monitor is an option that is under the Watchdog Timer Support option.
The Auto-monitor provides 4 mechanisms to feed the dog automatically.
I think the auto prefix stands for automatically,i.e., without the developer configuring it in execution code and the monitor word means that it will monitor your code because if one task gets stuck the timer will expire and the chip will be reseted.
There was a problem hiding this comment.
Ah, I get it: It is really built in monitoring the system and resetting the watchdog. "Enable Built in System Monitoring to reset the watchdog."
Is the timer one a HW timer off an ISR? Because WD kicking done off an ISR is a really bad idea.
There was a problem hiding this comment.
"Enable Built in System Monitoring to reset the watchdog." is a better title indeed.
The timer option calls wd_start in the beginning.
This function adds a watchdog timer to the active timer queue.
and registers a function that will be called from the interrupt level after the specified number of ticks has elapsed.
When this option is selected, the registered function resets the watchdog and calls wd_start again registering itself again.
It is implemented in drivers/timers/watchdog.c
There was a problem hiding this comment.
"Enable Built in System Monitoring to reset the watchdog." is a better title indeed.
I am easily confused by what I read a lot so I am glad it makes sense,
registers a function that will be called from the interrupt level after the specified number of ticks has elapsed.
Yikes, I would put a caution all over that to not to not use it, less one really knows what they are doing.,,,,,
| This command resets the watchdog timer ("ping", "pet the dog", "feed the dog"). | ||
|
|
||
| Using the Auto-monitor feature to keep the chip alive |
There was a problem hiding this comment.
Ah, I get it: It is really built in monitoring the system and resetting the watchdog. "Enable Built in System Monitoring to reset the watchdog."
Is the timer one a HW timer off an ISR? Because WD kicking done off an ISR is a really bad idea.
Co-authored-by: David Sidrane <David.Sidrane@Nscdg.com>
saramonteiro
force-pushed
the
wdt_doc
branch
from
e3dca25
to
e0732c9
Compare
| ``Timer callback``: This choice also uses a timer callback to reset the watchdog, but it will reset the watchdog every "keep a live interval". | ||
|
|
||
| ``Worker callback``: This choice uses the Low Priority Work Queue to reset the watchog every "keep a live interval". This choice depends on having the Low Priority Work Queue enabled. |
There was a problem hiding this comment.
not really need Low Priority Work Queue:
- If only high work enable, the high work queue is used
- otherwise the low work queue is used
This is because, low work queue will map to low work queue if only high work queue is enabled.
There was a problem hiding this comment.
Hum, so I'll change and add it as follows:
Worker callback: This choice uses a Work Queue to reset the watchdog every "keep a live interval". This choice depends on having the Low or High Priority Work Queue enabled.
If only the High Priority Work Queue is enabled, this one will be used, otherwise Low Priority Work Queue is used.
What do you think?
BTW, I thought it was only LPWORK because of the configuration:
work_queue(LPWORK, &upper->work, watchdog_automonitor_worker,
upper, WATCHDOG_AUTOMONITOR_PING_INTERVAL);
I didn't know the LPWORK was replaced by the HPWORK in case the latter was enabled and the former was not.
There was a problem hiding this comment.
Why invent terms? Keep alive -> Watchdog Reset interval
There was a problem hiding this comment.
@saramonteiro yes, it's accurate now, thanks.
There was a problem hiding this comment.
@davids5 I did not create terms like "Keep alive" and "pet the dog" or "ping".
Actually I just used the terms I saw in drivers/timers/watchdog.c and in include/nuttx/timers/watchdog.h
For example, the ioctl that feeds the dog is actually named WDIOC_KEEPALIVE.
My main goal with this PR is to document the WDT related features sticking to the current terms used in the source code.
There was a problem hiding this comment.
@xiaoxiang781216 thank you! =)
There was a problem hiding this comment.
@davids5 I did not create terms like "Keep alive" and "pet the dog" or "ping".
Actually I just used the terms I saw indrivers/timers/watchdog.cand ininclude/nuttx/timers/watchdog.h
For example, the ioctl that feeds the dog is actually namedWDIOC_KEEPALIVE.
My main goal with this PR is to document the WDT related features sticking to the current terms used in the source code.
Fare enough.
| ``Timer callback``: This choice also uses a timer callback to reset the watchdog, but it will reset the watchdog every "keep a live interval". | ||
|
|
||
| ``Worker callback``: This choice uses the Low Priority Work Queue to reset the watchog every "keep a live interval". This choice depends on having the Low Priority Work Queue enabled. |
There was a problem hiding this comment.
@davids5 I did not create terms like "Keep alive" and "pet the dog" or "ping".
Actually I just used the terms I saw indrivers/timers/watchdog.cand ininclude/nuttx/timers/watchdog.h
For example, the ioctl that feeds the dog is actually namedWDIOC_KEEPALIVE.
My main goal with this PR is to document the WDT related features sticking to the current terms used in the source code.
Fare enough.
|
Is it ready for merge? |
Summary
It describes how to use each auto monitor feature and briefly how it works.
Impact
N/A
Testing
N/A