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
