Softdevice s112 RTC0 timer callback

[astomi]

Hi,

SDK17, Softdevice S112, NRF52805 custom board. 

I have baremetal bsp implemented but I am new to Softdevice and struggling a bit with an interface concept beween two.

My peripheral needs to send periodically battery level info, in addition to the event driven sensor data.

I went through several BLE peripherals examples and most of them use app timers (RTC1) to schedule regular activity, however it seems that Softdevice can function wihithout app timers. For example Blinky calls only app_timer_init() but not app_timer_create() if I am not mistaken.

1. Hence my thinking - because every microamp counts, I would prefer to avoid using second (RTC1) instance if Softdevice able to generate an event/callback from RTC0. My app uses 25ms interval and 20-ish for Peripheral Latency so I would presume RTC0 should fire some internal event on 25x20 count match? Or I guess I could pipeline SAADS measurements and track(start SAADC) the end of radio tx (assuming tx is self-triggered inside Softdevice)?
   
   
2. If such event is available via Observer or whatever, would it be appropriate to start SAADC measurement (at max speed, doen't need to be very accurate) from such callback handler?
   
   
3. The other way around, when my app wants to send async data, can it call  sd_ble_gatts_hvx()  from within an interrupt handler? Data collection is done via ppi, so I guess I would need to use EGU to generate SWI as an interface for the outside world? Or sd_ble_gatts_hvx() must be called from main() context only?
   
   
4. My use case is very similar to the blood pressure measurement example but I can see it uses BLE Queue library (nrf_ble_gq_item_add() instead of sd_ble_gatts_hvx() call). Any specific reason for that? Especially within power consumption context?

Thanks for your help in advance.

[Einar Thorsrud]

Hi,

I would not recomend the approach you are considering here. It will likely lead to higher current consumption and added complexity.

1. You are right that the SoftDevice has no dependency on the app_timer, it uses RTC0 which is reserved for the SoftDevice. However, in practice virtuall all applications will need some form of low power timer, and app_timer represents that by making an arbitrary number of conceptual timers based on RTC1. The current consumption of an additional RTC instance is about 0.1 µA, which is negligible in most cases.

2. The SoftDevice use the RTC for other purposes, and does not forward interrupts for itself to the application. So in order to use the RTC0 wakeup you would need to do somethign like routing the RTC0 compare event to an EGU, and generate an interrupt form that. Then run software to check the elapsed time and evaluate if you have work to do or not. And if you do, trigger the SAADC or similar. I suspect this will lead to a higher average current consumption and added complexity. (I must also say that I have never seen this approach used.)

3. It is no problem making calls to sd_ble_gatts_hvx() provided the prioirity is lower (higher number) than the SoftDevice, see Interrupt priority levels.

4. The BLE GATT Queue library was added to most examples, but it is not requiered. It does not add to the idle current consumption in any way, but if you use it without needing it it will add additional CPU cycles which results in at least a theoretical increase in average power consumption.

PS: If you are starting development now, I woudl advice that you consider the nRF Connect SDK. See nRF Connect SDK and nRF5 SDK statement.

[astomi]

HI,

Thanks for this. Just to clarify couple of things.

1. 100nA is indeed insignificant, but where this number comes from? NRF52805 PS kind of suggests at least 300 nA (p.45 ION_RAMON_RTC_LFXO - ION_RAMON_EVENT)?
   
   
2. I have looked at the Queue library but the description has left me confused = "BLE GATT Queue module can be used to buffer BLE GATT requests if SoftDevice is not able to handle them at the moment". In both example types, say BPS and Power Profiling no attempt is made to check whether " SoftDevice is not able to handle" or deal with potential error (it just falls into APP_ERROR_HANDLER without retry). So question here is - if Softdevice even under ideal conditions can lose notification send requirest via hvx call, then queue is definitely required?
   
   
3. " BLE GATT Queue library ... It does not add to the idle current consumption in any way, but if you use it without needing it it will add additional CPU cycles"
   Could you please elaborate on "use without needing" a bit please?

[Einar Thorsrud]

Hi,

1. This number is the over all cunrrent consumption in that state, include regulators and LFCLK that are anyway active when you have the RTC0 running. Adding another RTC instance will add much less. The 100nA is from nRF52832 documentation, in practice I expect you will measure an even lower number if you compare a system with RTC0 only active and then add on RTC1.

2. The SoftDevice will not ignore API calls without returning an error, so if you check the return code and handles relevant values explicitly instead of calling APP_ERROR_HANDLER() for all, you can handle it specifically, and will not loose data.

3. It is just a generic remark. The GATT Queue library does not rely on any hardware, so the only way it can increase current consumption is by execurition time (CPU cycles). If you add code that does work that is not needed, it is wasted energy.