SoftDevice does 26ms of work inside first call to sd_app_evt_wait()

[charles]

nRF52832_XXAA, S132 v5.0.1, SDK 14.0.0

We enable SoftDevice via nrf_sdh_enable_request(). We immediately assert nrf_sdh_is_enabled() so we know it worked. On the first call to sd_app_evt_wait() we see SoftDevice take control of the CPU for 26ms. We have not started advertising or done any BLE work, the device is silent.

In certain boot conditions, this is fine and we don't care, SD can do what it wants. In other boot conditions, this 26ms work happens while we're doing open-loop battery measurement and powering the device off of a tiny capacitor. SD's mystery work immediately overwhelms this cap and the measurement aborts.

The code looks almost exactly like this:

nrf_sdh_enable_request();
volatile bool done = false;
while (!done) {
  sd_app_evt_wait();
}

Questions:

1. What is SD doing?

2. How do we know when SD will do work when we sleep?

3. Is there any API for us to test that SD is done with whatever its 26msec work is?

4. Will this work ever take more or less time than 26msec?

We need to know when it's safe to sleep for 125msec with no SD activity, or we can't boot correctly.

(Note that we used to enable SD after doing all of this work, but that led to a race when initializing the LFCLK so we enable SD very early now).

[charles]

(Using top-level reply because the "reply" and "verify answers" load asynchronously and sometimes just never show up)

Edvin, we need this behavior for the reasons I mention in the very first post:

"In certain boot conditions, this is fine and we don't care, SD can do what it wants. In other boot conditions, this 26ms work happens while we're doing open-loop battery measurement and powering the device off of a tiny capacitor. SD's mystery work immediately overwhelms this cap and the measurement aborts."

So, yes, we need absolutely control, or at least a normative statement from the SoftDevice team, that SoftDevice isn't going to wake up during our open-loop PMIC current measurement. If it does, the nRF52 draws too much current, and the measurement is aborted.

Sure, a 50msec sleep loop "fixed it" at my bench, but that doesn't mean it will work for every device at every temperature range in every environment at the field.

SoftDevice is an opaque binary and details like this are rarely documented, so DevZone support queries like this end up being the formal documentation.

I'd appreciate it if at this point we could move this discussion towards just getting me answers to the questions I've asked multiple times in this thread:

1. What is SoftDevice doing during this first sleep after enable but before BLE advertising?

2. Is there an API call that tells me if SoftDevice will take over the CPU when I call sd_app_evt_wait(), or for how long?

3. What is the upper bound in time for whatever this work is?

[Edvin]

Hello,

I am sorry that this takes some time, but I am surprised if the softdevice works for 26 ms in the first sd_app_evt_wait. Our softdevice team also thought this sounded strange. Do you have some FW that I can run on a DK that we can replicate this on, so that the softdevice team can have a look at what's going on?

They said: "I cannot understand how that code can run for several milliseconds unless they somehow make the WFE return immediately".

WFE in this case is referring to the WFE call inside sd_app_evt_wait().

Is it possible to provide a project so that we can investigate what's going on in the application?

Best regards,

Edvin

[charles]

I'm not sure that SD is actively using the CPU, only that the CPU is actively drawing current. This could be something like a PLL stabilization during LFCLK init, etc. My assumption is that there's an IRQ causing a context switch into SD right before the WFE runs, and SD is initializing some nRF52 peripheral block.

I'm not sure we can take the time to try and repro on a DK.

Before we take further steps, maybe the SD team could give a list of the peripheral blocks it enables in nrf_sdh_enable_request(), and what the current draw / time-to-stabilization data looks like?

[Edvin]

I can't give any detailed information about the softdevice, unfortunately, but they told me that there is nothing in the sd_app_evt_wait (or elsewhere in the softdevice without enabling advertising or a connection) that takes this much time. It should maximum use a couple of ms.

What is the difference between the HW you are using and the DK? Do you have any external components as well, connected by UART, SPI or I2C, that may be drawing power?

If you are only doing what you described, initialize softdevice and run into sd_app_evt_wait, it shouldn't be a problem to run it on a DK, but if you have some external components that are crucial for the reproduction, are they enabled? Maybe you have some peripheral that is not properly turned off, that are drawing the current that you are seeing?

Best regards,

Edvin