• State Verified Answer
  • Replies 11 replies
  • Subscribers 67 subscribers
  • Views 6858 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 114606
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Watchdog while in sd_app_evt_wait

Adrian Eggenberger

Hi

I've discovered last week some unexpected resets by the watchdog. I guess I've the explanation and the workaround for the behavior, but it would be great to have this assumption confirmed. Maybe some other peoples have similar behaviors.

The firmware is built on SDK11 and is based on a simple peripheral project. We have a watchdog configured with a time of five seconds and not running in sleep mode. We establish a connection from a smart device and than do no real data transfer. The call of sd_app_evt_wait by the application never returns, because the application has nothing to do (no interrupt causing the wakeup). After around 80 seconds the system resets caused by the watchdog.

My assumption is, that the softdevice internally wakes up for handling the BLE connection intervals. These ISR's are quite short, but the Watchdog counts up a bit at any wakeup. The application won't reset the watchdog because the call of sd_app_evt_wait never returns.

The solution I have is to configure at least a timer that forces the function sd_app_evt_wait to leave from time to time.

Can someone confirm this behavior? What is the best way to work around it?

Regards Adrian

  • 0

    yes that's right - and 5/80 sounds like about the right kind of duty cycle too, depends a bit what you're doing, just advertising it would be much longer, in connection it's working harder.

    And the correct solution is to have your own timer to feed the watchdog.

  • 0 in reply to RK

    Thanks for confirming this. I didn't think about the advertising, but it makes sense that the same effect happens there as well.

  • 0

    I have the same problem. I set the WD CRV at: 120s, 3s, 1s and 2/3s. My system woke up after: more than 2days, 135min, 45min and 30min, respectively. It's a big problem that we only can pause the WD.

    In my case, I stop all functions (including advertising) and clear all interrupts. BLE handling of the softdevice could be a reason. I'm not sure if there is some other automatic interrupts or not.

    I hope there will be a clear answer and solution for this situation.

  • 0

    I'm afraid I don't understand any part of your comment whatsoever. This question was about feeding the watchdog on a regular basis and whether sd_app_evt_wait() wakes up on a regular basis, which it doesn't, hence you need a timer to feed the watchdog. You seem to be talking about something entirely different..

  • 0

    Thank you for your quick reply. My trouble is: I use a WD and it is fed every 50ms when my system is working (advertising, reading data from a sensor via I2C port...) using a timer. The WD is set to pause in the Sleep mode. The function sd_app_evt_wait (or WFE()) is placed in the main loop so the system will be awoken up when there is some interrupt. When I would like to put my system into sleep mode to save energy, I disable all functions (advertising, reading sensors... and so on). It means sd_app_evt_wait() will put the chip into sleep mode. However, as I described above, after an amount of time, there is a reset and my system is awoken up. This amount of time is proportional to CRV values as in my test.

    Therefore, I think I have a same problem with Adrian Eggenberger that even when we put the system into sleep mode, sometimes the WD counter still increases. Until it reach the CRV value, WD will reset the chip.

Related