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 

 

[daviddedwin]

You can take a look at the softdevice specifications document (SDS) for more detailed information on the softdevice. I have pasted a snippet from one of the softdevice specirfication docs that clarifies your point.

I have posted a link to the document., look for the "download softdevice specification" on the right hand side.

5.3 Power management
The SoftDevice implements a simple to use SoftDevice Power API for optimized power management.
The application must use this API when the SoftDevice is enabled to ensure correct function. When the
SoftDevice is disabled, the application must use the hardware abstraction (CMSIS) interfaces for power
management directly.
When waiting for application events using the API, the CPU goes to an IDLE state whenever the SoftDevice
is not using the CPU, and interrupts handled directly by the SoftDevice do not wake the application.
Application interrupts will wake the application as expected. When going to system OFF, the API ensures
the SoftDevice services are stopped before powering down.

Please accept my answer if this is helpful.

[astella]

Thank you very much Sir for your reply.