microcontroller behaviour after calling sd_app_evt_wait

[astella]

To the kind attention of Nordic support team,

I'm interested in understanding in a conceptual way, how the microcontroller is operating when sd_app_evt_wait is called.

Let's suppose that the micro plays the peripheral role and a BLE connection is already established with a BLE host. After 

that, calling sd_app_evt_wait should make it possible to have the micro in System On sleep mode; nevertheless the BLE connection remains alive,

so I assume there is some periodic activity going on. I'd like to understand if this periodic activity is somehow carried on by the RADIO peripheral without any CPU intervention,

or CPU intervention is periodically required, so that the microcontroller is periodically waken up so to handle the ble stack at softdevice level, and then

it goes to sleep again until a specific user defined condition is reached? (For example a GPIO sense interrupt)

I saw that if a BLE disconnection occurs while the peripheral device is in System On sleep mode, there is no chance to re-establish it, unless the sleep mode is exited.

So, I assume that during sleep mode the background activity is only meant to keep alive the BLE channel, without any possible high level intervention.

Would be appreciated if you could please clarify me how that background activity takes place and if possible point me to the right documentation. Thank you for your help

Best regards 

 

[astella]

Ok. I got what I was searching for and I have a much more clear understanding about that. Let me please share the result.

1) when in SystemOn Sleep mode, softdevice is perfectly able to properly maintain a BLE channel alive working in background, generally without any application level CPU intervention is needed

2) I used sd_app_evt_wait to enter SystemOn Sleep mode. I'm working in a project that has got FreeRTOS and BLE and a custom precise point where to go to sleep, until a well defined user event wakes up the CPU. I found convenient to use this sort of loop:

while(! user defined condition){

  sd_app_evt_wait()

}

3) At this point the CPU is correctly sleeping and power consumption is only some uAmps. But there is a problem! The softdevice, that is able to work in background, needs at some point to forward certain BLE events to the app level BLE stack. For example in case of BLE disconnection, having something like 2) is not ok.

4) One solution to get low power consumption and the BLE stack responsive, is in my case to use nrf_sdh_evts_poll. Something like this:

while(! user defined condition){

  sd_app_evt_wait()

  nrf_sdh_evts_poll()

}

Thank you, best regards

[Vidar Berg]

Thanks for the update. Regarding your last three points, please note that the Freertos BLE example already has an idle thread that puts the device in system ON when there are no pending tasks. It does so by calling the vPortSuppressTicksAndSleep() function. 

Also, the Softdevice events should only be polled by the softdevice_task in nrf_sdh_freertos.c.

[astella]

Thank you very much Vidar for your comments. Yes, before that loop we have a custom prepare sleep that is also switching off the rtos, basically stopping its rtc timer. So that there is no any race condition in using again _sdh_evts_poll

Also in case could be useful for someone, about vPortSuppressTicksAndSleep, it is also possible to read this link (also mentioned in Nordic dev zone threads) 

https://jimmywongiot.com/2019/07/31/current-consumption-with-freertos-on-nordic-nrf5-sdk/

[Vidar Berg]

Then it makes sense I didn't know you had turned off the scheduler.