This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Disabling the softdevice hangs when using LFRC with an active watchdog

Using LFRC as the softdevice LFCLK source, enabling and running the WDT causes the softdevice to hang until the watchdog reset when calling nrf_sdh_disable_request. This is with SDK v15.3.0 on both S112 and S140.

Configuring the WDT to pause on debugging, I was able to trace the call to following:

1. nrf_sdh_disable_request
2. sdh_state_observer_notify
3. handler(evt, p_observer->p_context) (which is sd_state_evt_handler in the first iteration of my loop)
4. nrfx_clock_enable
5. nrf_drv_clock_lfclk_release
6. lfclk_stop
7. nrfx_clock_lfclk_stop
8. while(nrf_clock_lf_is_running()). <--- Hangs here (nrfx_clock.c:245)
The PS states "When started, the watchdog will automatically force the 32.768 kHz RC oscillator on as long as no other 32.768 kHz clock source is running and generating the 32.768 kHz system clock".
Therefore, I presume that the hang is caused from the softdevice entering a blocking while loop waiting for an LFCLK src to stop that never will because of the WDT.

Given the functions below, I don't see a way for the softdevice to successfully disable while using an LFRC that is also in use by the WDT, without registering an m_clock_cb.lfclk_requests, which the nrfx_wdt drivers do not appear to do:

Am I missing a softdevice call or step that enables it to proceed while sharing the LFCLK source with WDT?

Here are my clock settings for the softdevice:


Commenting out the call to nrf_drv_clock_lfclk_release or lfclk_stop prevents the hang.

Also, if I switch NRF_SDH_CLOCK_LF_SRC to LFSYNT, the softdevice disables successfully without any hanging.  However, the softdevice documentation states that there are only two sources usable for the softdevice: the internal RC and XTAL.

Is LFSYNT not recommended for the softdevice? Or is this a valid alternative as an "internal RC" if the additional current consumption is acceptable?

Parents
  • Hi,

    I think you can see this as a bug in the clock drivers. I have reported it internally. 

    I am not sure exactly where this should be fixed. If you tell nrfx to disable the clock by calling nrfx_clock_lfclk_stop(), it could perhaps return an error if the watchdog is enabled, or silently handle this by not waiting for the clock to stop if the watchdog timer is ready. Alternatively, you could modify sd_state_evt_handler() to not call nrf_drv_clock_lfclk_release() on the NRF_SDH_EVT_STATE_DISABLED event as you do, or check if the WDT is enabled, and only call it if not.

Reply
  • Hi,

    I think you can see this as a bug in the clock drivers. I have reported it internally. 

    I am not sure exactly where this should be fixed. If you tell nrfx to disable the clock by calling nrfx_clock_lfclk_stop(), it could perhaps return an error if the watchdog is enabled, or silently handle this by not waiting for the clock to stop if the watchdog timer is ready. Alternatively, you could modify sd_state_evt_handler() to not call nrf_drv_clock_lfclk_release() on the NRF_SDH_EVT_STATE_DISABLED event as you do, or check if the WDT is enabled, and only call it if not.

Children
  • Thanks a lot, Einar!

    I like the idea of some sort of notification being returned about the driver not being able to shut down its LFCLK. Then an app could decide to ignore this or handle it as needed.

    For the softdevice, if the WDT is running then caring about the LFRC getting shut down is kind of moot, so maybe some sort of error check or "if !(WDT is running && softdevice LFCLK == LFRC)" guard around the call for would suffice there.