drivers/wdt: add periph_wdt_auto_start for early watchdog #18257
Conversation
There was a problem hiding this comment.
I do like this. But I would like a word if warning in the doc that this is not exactly best practice on how to implement a watchdog. Typically, one would want to check in the application has made some "progress" since the last time the watchdog was fed before feeding it again.
But I doubt that this can be done in a generalized way without knowing the application and this would still be better than no watchdog at all. So this could be a quick tool to improve robustness of a firmware a bit with no effort spent.
sys/auto_init/wdt/wdt.c
Outdated
| / 2; | ||
| while (1) { | ||
| ztimer_sleep(ZTIMER_MSEC, sleep_ms); | ||
| wdt_kick(); |
There was a problem hiding this comment.
I wonder if we could have some trivial cheap plausibility check here. E.g. if all threads are waiting for a mutex hold by another thread, the application is in a deadlock but this thread would still happily feed the watchdog. But I don't really know how to tell a thread waiting on an IRQ to unlock a mutex from a thread waiting on another thread apart.
3e5eb47
to
fbff8a4
Compare
Add an option to enable the watchdog early to detect hangs during initialisation.
be447f2
to
14ff008
Compare
14ff008
to
6e8aebd
Compare
|
lgtm. To me, |
6e8aebd
to
80fe4e5
Compare
|
Good point, added. |
|
bors merge |
18257: drivers/wdt: add periph_wdt_auto_start for early watchdog r=benpicco a=benpicco 19272: gcoap: Do not send responses from multicast addresses r=chrysn a=chrysn ### Contribution description Since #18026, CoAP requests to multicast addresses (eg. `ff02::1`) came back from that exact address, which Linux rightfully just drops. The fix uses the existing multicast check from #17978 (thanks `@benpicco` for making me write this as dedicated function, I just had to generalize it removing one struct layer), and foregoes setting the source address when responding to multicasts. ### Testing procedure * Run the gcoap example * Send a CoAP request to a multicast address RIOT listens to, eg. `./aiocoap-client coap:https://'[ff02::1%tapbr0]'/.well-known/core --non` Before, this got no response (while you see it arrive on wireshark). After, you get a correct response with two lines of note: ``` WARNING:coap:Sending request to multicast via unicast request method Response arrived from different address; base URI is coap:https://[fe80::3c63:beff:fe85:ca96%tapbr0]/.well-known/core ``` (The former is aiocoap telling us that we're not using the nonexistent multicast API so it's really more of an anycast, the latter is useful factual information). Co-authored-by: Benjamin Valentin <[email protected]> Co-authored-by: chrysn <[email protected]>
|
This PR was included in a batch that was canceled, it will be automatically retried |
|
Build succeeded: |
Contribution description
Add an option to enable the watchdog early to detect hangs during initialization.
Testing procedure
Add
USEMODULE += auto_init_wdt_threadorUSEMODULE += auto_init_wdt_eventto your application.This will automatically spawn a watchdog thread that runs with the lowest priority.
Issues/PRs references