Writing to external Flash over QSPI leaves a 400μA current until bluetooth advertising gets called.

[M.A.]

Hello

I'm currently writing a program for an NRF52840 chip which reads some values from an ADC each second and writes them to an external flash chip.
I'm trying to run this with a low power consumption.
This chip is connected with QSPI. I'm using Zephyr to do this.

This implementation uses the driver in nrf_qspi_nor.c.
In the image below you can see the regular spikes being the BLE advertising at 100ms and additionally my 1Hz code at the second spike.

As you can see after my call to flash_write() the current stays on 400μA until the advertising spike happens.
I verified that it has to be this call, as the current doesn't appear if I comment theflash_write out, or replace it with a flash_read.

And the current doesn't ever stop on its own either. If I slow down the advertising rate the current will stay on even longer.

Could anyone help me with getting rid of this current? Or at least help me understand where it's coming from, and why the advertising clears it?

Greetings

Edit 1:

I've tried some other things and found out that the error doesn't happen if I set:

PM_DEVICE_RUNTIME=n

For the above post I've been running the following settings:

CONFIG_PM=y

CONFIG_PM_DEVICE=y

CONFIG_PM_DEVICE_RUNTIME=y

Even though it doesn't appear to change much of anything according to the measurement with PPK2.

Edit 2:

Turns out I was looking at the wrong place after all. I was now able to narrow the error down to a call of k_uptime_get()

Furthermore the error happens exactly 31 times and then disappears.

[Jared]

Hi there,

Could you try the workaround suggested here and see if it lowers the current consumption?

regards

Jared

[M.A.]

Hi Jared

I've already tried that earlier. But as the two Edits stated the error actually lied somewhere else.

In the meantime I found the actual error.

We assume it was caused by us calculating the sleep time inside the K_MSEC() macro in a call to k_sleep().

After moving the calculation out of that call, it appears to finally work.

I was gonna delete this, when I saw your reply, since the title now has nothing at all to do with the actual problem.

[Jared]

M.A. said:

In the meantime I found the actual error.

We assume it was caused by us calculating the sleep time inside the K_MSEC() macro in a call to k_sleep().

After moving the calculation out of that call, it appears to finally work.

I see, well, I'm happy that you found the solution.

Marking this as verified then,

best regards

Jared