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

S132 sd_app_evt_wait() blocks for seconds during connection

I am running an appliction with S132 soft device, build on top of SDK 12.0.0. Problem is that the application sometimes stops running for ten seconds, or even more, when Bluetooth connection is established. According to my debug-prints it looks like sd_app_evt_wait() just blocks. I have an app_timer running at the rate of 10 Hz, but this doesn't wake up system from the sd_app_evt_wait() in that case.

Is that normal behaviour of soft device S132, or what could cause the problem? Any hints to overcome the problem? In the phone end Android application thinks it is connected, but no data comes in, except the battery value. I am using Nordic UART service ("nus") to send out data from the nRF52832.

Parents
  • sd_app_evt_wait() does not block. It does the same as __WFE() and in addition checks whether the interrupt that woke up the CPU is SoftDevice specific (like RADIO, TIMER0 or RTC0) or application specific, in which case it will jump to the application/return from the function.

    My guess is that you are running code from interrupt context all the time, therefore never executing the app_timer calls or never going to sleep. You can check if this is the case by measuring the current consumption. If the current consumption never goes to 2-3uA (or a couple of 100s uA if you are running timers or similar), then you know that the application is not returning to sleep, i.e. never calling sd_app_evt_wait().

Reply
  • sd_app_evt_wait() does not block. It does the same as __WFE() and in addition checks whether the interrupt that woke up the CPU is SoftDevice specific (like RADIO, TIMER0 or RTC0) or application specific, in which case it will jump to the application/return from the function.

    My guess is that you are running code from interrupt context all the time, therefore never executing the app_timer calls or never going to sleep. You can check if this is the case by measuring the current consumption. If the current consumption never goes to 2-3uA (or a couple of 100s uA if you are running timers or similar), then you know that the application is not returning to sleep, i.e. never calling sd_app_evt_wait().

Children
No Data
Related