Reduce power consumption through dynamic HFXO request/release operations with softdevice

[Alec Werning]

We have a BLE, battery powered device where we'd like to enter low power modes whenever possible by dynamically switching between HFXO and HFINT such that our application only enables the HFXO when performing a set of actions requiring a more accurate clock source. We recently introduced an application level method to request and release the HFXO clock (via nrfx's nrf_drv_clock_hfclk_request and nrf_drv_clock_hfclk_release) for occasional application behavior not related to BLE that needs HFXO enabled for clock accuracy. The SoftDevice is also present and handling BLE operations with the HFXO as expected.

Despite adding the app level HFXO interaction, the request and release calls (via nrf_drv_clock_hfclk_request  and nrf_drv_clock_hfclk_release ) hard fault when the soft device service call occurs (hard fault traced to sd_clock_hfclk_request/release ).

Device context:

• nRF5 SDK v15.3.0 (S140 SoftDevice v6.1.1)
• nrf52840 with external crystal oscillator (64 MHz driven by 32 MHz crystal)

Existing Nordic Q&A posts:

• sd_clock_hfclk_request() hard fault
  • similar but our request/release of the HFXO does not occur from an interrupt handler
• timeslot - how turn off hfclk crystal
  • situation where Radio Timeslot is being utilized to toggle the clock - is this a recommend way to share HXFO state handling with the softdevice?
• Other related post (like this nrf51 post) don't seem to apply to this nrf52/s140 setup

Are there any obvious barriers to dynamically requesting and releasing the HFXO from the app level when the SoftDevice is present?

Does Nordic have any examples or documentation where such an interaction with the HFXO occurs?

[Jared]

Hi,

Are there any obvious barriers to dynamically requesting and releasing the HFXO from the app level when the SoftDevice is present?

As long as you go through the Softdevice API then it should be fine, 

We recently introduced an application level method to request and release the HFXO clock (via nrfx's nrf_drv_clock_hfclk_request and nrf_drv_clock_hfclk_release) for occasional application behavior not related to BLE that needs HFXO enabled for clock accuracy. The SoftDevice is also present and handling BLE operations with the HFXO as expected.

Can share this code?

regards

Jared 

[Alec Werning]

Thanks for the response, Jared. We've managed to identify the root cause of our issue.

Root cause:

• We are calling nrf_drv_clock_hfclk_request/release from a FreeRTOS critical section taskENTER_CRITICAL() in our application
• Our critical section blocked the underlying sd_clock_hfclk_request/release calls which are designated as a level 4 interrupt priority level.

Paths forward:

• Alter the critical section definition to block at lower interrupt priority levels (and therefore allow the SD API at level 4 which may not be feasible or safe)
• Move away from the critical section and implement thread protection via something like a binary semaphore