SoftDevice preventing low-power state

Question

I'm working on a BLE design for nRF52832, with SoftDevice S132 v5.0.0. The project uses FreeRTOS with Tickless Idle enabled. When the user powers the device off (from a UI perspective, not actually cutting power to the uP) there should be almost nothing happening and the device should go into System-on low-power for an extended period of time (seconds, if not longer). What I'm seeing, however, is that FreeRTOS calls sd_app_evt_wait() but that function returns very quickly (within about 5us) and there is no power saving. 
 When entering the device-off state, we call sd_ble_gap_disconnect(), ble_advertising_start(&m_advertising, BLE_ADV_MODE_IDLE) , and sd_ble_gap_adv_stop() which I think should be enough to ensure the SoftDevice is completely idle. 
 If I *also* call nrf_sdh_disable_request() to disable the SoftDevice, then FreeRTOS calls __WFE() and the device sees significant power savings. 
 I would really prefer not to have to disable the SoftDevice in order to achieve useful power savings. Is there something I can do to figure out why it's not actually sleeping when I think it should be? 
 Thanks, --Russ

rnelson · Accepted Answer

It turns out our main issue was Anomaly 87 (FPU exception preventing low power), but I also implemented Austin's suggestion since I was sometimes seeing the SoftDevice bounce out of sd_app_evt_wait() immediately.

Austin · Answer

I also saw this behaviour with nRF52840 and S140 where sd_app_evt_wait() would return immediately on the first call when entering tickless idle. I proposed a different method for entry/exit to idle in this post. The code attached to that post will stay in an inner loop around sd_app_evt_wait() until there is a runnable task or the idle time has expired. From memory, the profiling counters in the inner loop show that sd_app_evt_wait() is almost always executed at least twice when entering idle, showing that the first sd_app_evt_wait() drops through. There are some current consumption numbers listed which show the difference between normal tickless and my proposed changes.

SoftDevice preventing low-power state

Top Replies