This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

microcontroller behaviour after calling sd_app_evt_wait

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 

 

Parents
  • 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

Reply
  • 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

Children
No Data
Related