drivers/wdt: add periph_wdt_auto_start for early watchdog#18257
drivers/wdt: add periph_wdt_auto_start for early watchdog#18257bors[bot] merged 2 commits intoRIOT-OS:masterfrom
Conversation
github-actions
bot
added
Area: build system
maribu
left a comment
maribu
left a comment
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.
| / 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.
benpicco
force-pushed
the
periph_wdt_auto_start
branch
from
3e5eb47 to
fbff8a4
Compare
Add an option to enable the watchdog early to detect hangs during initialisation.
benpicco
force-pushed
the
periph_wdt_auto_start
branch
from
be447f2 to
14ff008
Compare
benpicco
added
the
CI: ready for build
benpicco
force-pushed
the
periph_wdt_auto_start
branch
from
14ff008 to
6e8aebd
Compare
|
lgtm. To me, |
benpicco
force-pushed
the
periph_wdt_auto_start
branch
from
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://'[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://[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: |
4 participants
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