Sharing the HFXO on the nRF series

[Amr Bekhit <am...@gmail.com>]

Hello all,

I'm currently working on a project using mynewt 1.5.0 that will use
both the BLE and LoRa stacks and needs to run at low power. This
requires that the high frequency crystal oscillator (HFXO) be turned
on and off as required, rather than staying always on (it consumes
around 400uA). After looking through the BLE and LoRa stacks I noticed
the following:

- The BLE stack requires the use of the nRF HFXO and contains code to
turn it on and off as required, thus keeping power consumption low.
- The LoRa stack uses the hal_timer functions as part of the critical
timing needed when transmitting and receiving. The nRF hal_timer
functions automatically turn on the HFXO (in hal_timer_config). The
LoRa stack does no power management, with the timer initialised at the
start and running indefinitely.
- The LoRa stack uses the hal_timer for ALL timing tasks, including
non-critical ones.

At the moment, it seems like it wouldn't be possible to run both the
BLE and LoRa stacks at the same time, as the BLE stack could turn the
HFXO off and thus inadvertently reduce the accuracy of the LoRa timers
and cause reception problems.  In order to solve this, I started work
on a centralised HFXO manager whereby code would request that the HFXO
be turned on and notify when it no longer needs it. The manager would
then keep the HFXO on as long as there was at least one active
request, shutting it down when all requests were released.

At the same time, I've been modifying the LoRa stack so that
non-critical timing functions use the os_cputime routines, and that
only the critical timing code (receive window timing) uses the
hal_timers. The HFXO manager would then request the HFXO be turned on
and off only as required.

I've since had a look at the latest master branch on github and
noticed that Will has already committed code that implements an HFXO
manager (https://github.com/apache/mynewt-core/blob/master/hw/mcu/nordic/nrf52xxx/src/nrf52_clock.c).
However, searching through the github repo, it doesn't appear that
this code is used at all (yet).

What are the current plans regarding the HFXO manager? In my own
implementation attempt, I replaced all code that starts the HFXO with
calls to the manager. These are the following places (for both the
nRF52 and nRF51):
- ble_phy.c
- hal_system.c (if the synthesised 32kHz clock is enabled)
- hal_timer.c (in hal_timer_config - I also added a shutdown request
in hal_deinit).

For the purposes of not duplicating work, I'm interesting in finding
out what you guys plan on doing regarding these features.

Amr

Re: Sharing the HFXO on the nRF series

[will sanfilippo <wi...@runtime.io>]

Amr:

I cannot answer your question regarding what plans folks may have on using the HFXO manager. Generally I would think folks would send an email to this list if they had any plans…

I think something was missed in the initial implementation of the nRF hal_timers and the HFXO. Well, maybe simply just assumed. The assumption, and this assumption was certainly made in regards to os_cputime, was that these timers would be both “high_resolution” and “high accuracy”. The former is of little consequence but the latter is not, as it would require the HFXO to be turned on (which consumes a lot more power).

I certainly think that there needs to be some changes in the “high accuracy” area. I am not sure what this would be but one thing I was considering was to create a MYNEWT variable that you could set on a either a “mcu-wide” basis or on a per-timer basis that would basically mark that timer as a “high-accuracy” timer. The effects of this would be mcu-specific and in the case of the nRF series would turn on the HFXO (and thus use the HFXO manager). In this way the application develop can decide if they need a more accurate time base.

For example: HAL_TIMER_HIGH_ACCURACY (mcu-wide) or HAL_TIMER_0_HIGH_ACCURACY (timer specific). If set to true, HFXO manager used to use/stop using HFXO.


> On Jan 10, 2019, at 12:44 PM, Amr Bekhit <am...@gmail.com> wrote:
> 
> Hello all,
> 
> I'm currently working on a project using mynewt 1.5.0 that will use
> both the BLE and LoRa stacks and needs to run at low power. This
> requires that the high frequency crystal oscillator (HFXO) be turned
> on and off as required, rather than staying always on (it consumes
> around 400uA). After looking through the BLE and LoRa stacks I noticed
> the following:
> 
> - The BLE stack requires the use of the nRF HFXO and contains code to
> turn it on and off as required, thus keeping power consumption low.
> - The LoRa stack uses the hal_timer functions as part of the critical
> timing needed when transmitting and receiving. The nRF hal_timer
> functions automatically turn on the HFXO (in hal_timer_config). The
> LoRa stack does no power management, with the timer initialised at the
> start and running indefinitely.
> - The LoRa stack uses the hal_timer for ALL timing tasks, including
> non-critical ones.
> 
> At the moment, it seems like it wouldn't be possible to run both the
> BLE and LoRa stacks at the same time, as the BLE stack could turn the
> HFXO off and thus inadvertently reduce the accuracy of the LoRa timers
> and cause reception problems.  In order to solve this, I started work
> on a centralised HFXO manager whereby code would request that the HFXO
> be turned on and notify when it no longer needs it. The manager would
> then keep the HFXO on as long as there was at least one active
> request, shutting it down when all requests were released.
> 
> At the same time, I've been modifying the LoRa stack so that
> non-critical timing functions use the os_cputime routines, and that
> only the critical timing code (receive window timing) uses the
> hal_timers. The HFXO manager would then request the HFXO be turned on
> and off only as required.
> 
> I've since had a look at the latest master branch on github and
> noticed that Will has already committed code that implements an HFXO
> manager (https://github.com/apache/mynewt-core/blob/master/hw/mcu/nordic/nrf52xxx/src/nrf52_clock.c).
> However, searching through the github repo, it doesn't appear that
> this code is used at all (yet).
> 
> What are the current plans regarding the HFXO manager? In my own
> implementation attempt, I replaced all code that starts the HFXO with
> calls to the manager. These are the following places (for both the
> nRF52 and nRF51):
> - ble_phy.c
> - hal_system.c (if the synthesised 32kHz clock is enabled)
> - hal_timer.c (in hal_timer_config - I also added a shutdown request
> in hal_deinit).
> 
> For the purposes of not duplicating work, I'm interesting in finding
> out what you guys plan on doing regarding these features.
> 
> Amr