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]

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.

[astella]

5)  Another improvement, in case freertos has been stopped before entering this sleeping loop, could be something like this:

while(! user defined condition){

      sd_app_evt_wait()

      nrf_sdh_evts_poll()

      if(p_ble_evt->header.evt_id == xxx)

        break;

}

_restart freertos.

In case you want to process xxx using your application layer as usual. In nrf_sdh_ble_evts_poll just check p_ble_evt->header.evt_id that is

important to propagate to the application layer. 

For example in my case ignoring ble evt 0x57 I allow the sleeping loop to be effective, with a very low power consumption. I exit that loop for

every event that is not 0x57. 

6)

while(! user defined condition){

      sd_app_evt_wait()

      nrf_sdh_evts_poll()

      if(p_ble_evt->header.evt_id != 0x57)

        break;

}

_restart freertos

https://devzone.nordicsemi.com/f/nordic-q-a/48357/what-does-the-ble-event-0x57-mean

Thank you, best regards

[astella]

It seems that there are ble handlers that are using freertos, like during connection parameters negotations (conn_params_negotiation). A software freertos timer is needed and freertos scheduler should be running. It is a very fascinating subject, and the more I'm studying and testing a "home made" architecture of freertos, softdevice and sleeping mode, the more I'm understanding the problems related. So next days I'll get started testing what Vidar Berg is suggesting. Thank you