Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

75%
+4 −0
Q&A Is Feeding a Watchdog Timer from an ISR a Bad Practice?

In an embedded system, I require a watchdog to be able to pass ESD qualifications (the main reason for the watchdog requirement is that the device wasn't able to pass the harshest tests of the IEC ...

2 answers  ·  posted 1mo ago by drkfrx‭  ·  edited 29d ago by drkfrx‭

#4: Post edited by user avatar drkfrx‭ · 2024-12-20T13:31:23Z (29 days ago)
Added missing link to memfault article
  • In an embedded system, I require a watchdog to be able to pass ESD qualifications (the main reason for the watchdog requirement is that the device wasn't able to pass the harshest tests of the IEC 61000-4-2 standard). Having no experience with watchdogs, I went through this Memfault article. I liked the events "registration" and "flags" since it easily allows us to do conditional ORing of events depending on the system's state. Plus it feels scalable.
  • For the feeding part, here's what I put in place:
  • ```c
  • /** @brief Raise the event flag and feed the watchdog if all required event flags are set.
  • *
  • * @param[in] event_flag Bitmask corresponding to the triggering event.
  • */
  • static void watchdog_feed_if_all_events_set(watchdog_event_t event_flag)
  • {
  • /* Declare as volatile since this function could be called from concurrent ISRs. */
  • static volatile watchdog_event_t watchdog_fed_events;
  • enter_critical();
  • watchdog_fed_events |= event_flag;
  • if ((watchdog_fed_events & watchdog_required_events) == watchdog_required_events) {
  • bsp_watchdog_feed();
  • watchdog_fed_events = 0;
  • }
  • exit_critical();
  • }
  • ```
  • This function can then be called from any part of the application, including from ISRs.
  • Now for the question:
  • I was told it was senseless to feed a watchdog from an ISR and that a redesign is required, but no rationale was provided. I see nothing wrong with my implementation and it works just fine. I feel like a watchdog design is closely related/dependent to the system on which it is implemented and that there are no one-size-fits-all designs.
  • Am I missing something? Why would someone want to avoid feeding a watchdog from an ISR?
  • In an embedded system, I require a watchdog to be able to pass ESD qualifications (the main reason for the watchdog requirement is that the device wasn't able to pass the harshest tests of the IEC 61000-4-2 standard). Having no experience with watchdogs, I went through [this Memfault article](https://interrupt.memfault.com/blog/firmware-watchdog-best-practices). I liked the events "registration" and "flags" since it easily allows us to do conditional ORing of events depending on the system's state. Plus it feels scalable.
  • For the feeding part, here's what I put in place:
  • ```c
  • /** @brief Raise the event flag and feed the watchdog if all required event flags are set.
  • *
  • * @param[in] event_flag Bitmask corresponding to the triggering event.
  • */
  • static void watchdog_feed_if_all_events_set(watchdog_event_t event_flag)
  • {
  • /* Declare as volatile since this function could be called from concurrent ISRs. */
  • static volatile watchdog_event_t watchdog_fed_events;
  • enter_critical();
  • watchdog_fed_events |= event_flag;
  • if ((watchdog_fed_events & watchdog_required_events) == watchdog_required_events) {
  • bsp_watchdog_feed();
  • watchdog_fed_events = 0;
  • }
  • exit_critical();
  • }
  • ```
  • This function can then be called from any part of the application, including from ISRs.
  • Now for the question:
  • I was told it was senseless to feed a watchdog from an ISR and that a redesign is required, but no rationale was provided. I see nothing wrong with my implementation and it works just fine. I feel like a watchdog design is closely related/dependent to the system on which it is implemented and that there are no one-size-fits-all designs.
  • Am I missing something? Why would someone want to avoid feeding a watchdog from an ISR?
#3: Post edited by user avatar Nick Alexeev‭ · 2024-12-17T15:59:07Z (about 1 month ago)
#2: Post edited by user avatar drkfrx‭ · 2024-12-17T15:11:00Z (about 1 month ago)
Added more information regarding the ESD tests
  • In an embedded system, I require a watchdog to be able to pass ESD qualifications. Having no experience with watchdogs, I went through this Memfault article. I liked the events "registration" and "flags" since it easily allows us to do conditional ORing of events depending on the system's state. Plus it feels scalable.
  • For the feeding part, here's what I put in place:
  • ```c
  • /** @brief Raise the event flag and feed the watchdog if all required event flags are set.
  • *
  • * @param[in] event_flag Bitmask corresponding to the triggering event.
  • */
  • static void watchdog_feed_if_all_events_set(watchdog_event_t event_flag)
  • {
  • /* Declare as volatile since this function could be called from concurrent ISRs. */
  • static volatile watchdog_event_t watchdog_fed_events;
  • enter_critical();
  • watchdog_fed_events |= event_flag;
  • if ((watchdog_fed_events & watchdog_required_events) == watchdog_required_events) {
  • bsp_watchdog_feed();
  • watchdog_fed_events = 0;
  • }
  • exit_critical();
  • }
  • ```
  • This function can then be called from any part of the application, including from ISRs.
  • Now for the question:
  • I was told it was senseless to feed a watchdog from an ISR and that a redesign is required, but no rationale was provided. I see nothing wrong with my implementation and it works just fine. I feel like a watchdog design is closely related/dependent to the system on which it is implemented and that there are no one-size-fits-all designs.
  • Am I missing something? Why would someone want to avoid feeding a watchdog from an ISR?
  • In an embedded system, I require a watchdog to be able to pass ESD qualifications (the main reason for the watchdog requirement is that the device wasn't able to pass the harshest tests of the IEC 61000-4-2 standard). Having no experience with watchdogs, I went through this Memfault article. I liked the events "registration" and "flags" since it easily allows us to do conditional ORing of events depending on the system's state. Plus it feels scalable.
  • For the feeding part, here's what I put in place:
  • ```c
  • /** @brief Raise the event flag and feed the watchdog if all required event flags are set.
  • *
  • * @param[in] event_flag Bitmask corresponding to the triggering event.
  • */
  • static void watchdog_feed_if_all_events_set(watchdog_event_t event_flag)
  • {
  • /* Declare as volatile since this function could be called from concurrent ISRs. */
  • static volatile watchdog_event_t watchdog_fed_events;
  • enter_critical();
  • watchdog_fed_events |= event_flag;
  • if ((watchdog_fed_events & watchdog_required_events) == watchdog_required_events) {
  • bsp_watchdog_feed();
  • watchdog_fed_events = 0;
  • }
  • exit_critical();
  • }
  • ```
  • This function can then be called from any part of the application, including from ISRs.
  • Now for the question:
  • I was told it was senseless to feed a watchdog from an ISR and that a redesign is required, but no rationale was provided. I see nothing wrong with my implementation and it works just fine. I feel like a watchdog design is closely related/dependent to the system on which it is implemented and that there are no one-size-fits-all designs.
  • Am I missing something? Why would someone want to avoid feeding a watchdog from an ISR?
#1: Initial revision by user avatar drkfrx‭ · 2024-12-17T14:53:59Z (about 1 month ago)
Is Feeding a Watchdog Timer from an ISR a Bad Practice?
In an embedded system, I require a watchdog to be able to pass ESD qualifications. Having no experience with watchdogs, I went through this Memfault article. I liked the events "registration" and "flags" since it easily allows us to do conditional ORing of events depending on the system's state. Plus it feels scalable.

For the feeding part, here's what I put in place:

```c
/** @brief Raise the event flag and feed the watchdog if all required event flags are set.
 *
 *  @param[in] event_flag  Bitmask corresponding to the triggering event.
 */
static void watchdog_feed_if_all_events_set(watchdog_event_t event_flag)
{
    /* Declare as volatile since this function could be called from concurrent ISRs. */
    static volatile watchdog_event_t watchdog_fed_events;

    enter_critical();

    watchdog_fed_events |= event_flag;

    if ((watchdog_fed_events & watchdog_required_events) == watchdog_required_events) {
        bsp_watchdog_feed();
        watchdog_fed_events = 0;
    }
    exit_critical();
}
```

This function can then be called from any part of the application, including from ISRs.

Now for the question:

I was told it was senseless to feed a watchdog from an ISR and that a redesign is required, but no rationale was provided. I see nothing wrong with my implementation and it works just fine. I feel like a watchdog design is closely related/dependent to the system on which it is implemented and that there are no one-size-fits-all designs.

Am I missing something? Why would someone want to avoid feeding a watchdog from an ISR?