Hi,
in some earlier discussions
https://devzone.nordicsemi.com/f/nordic-q-a/58652/additional-questions-to-nrf52832-errata-220-clearification
and
https://devzone.nordicsemi.com/f/nordic-q-a/58488/nrf52832-errata-220-clearification-need-more-information
I asked how to use the work-a-round for errata 220. Therefore I did following implementation.
I replaced (in nrf_soc.h):
SVCALL(SD_APP_EVT_WAIT, uint32_t, sd_app_evt_wait(void));
with:
__STATIC_INLINE uint32_t sd_app_evt_wait (void)
{
SCB->SCR |= SCB_SCR_SEVONPEND_Msk;
__disable_irq();
__WFE(); // workaround implemented
__NOP();__NOP();__NOP();__NOP();
__enable_irq();
return NRF_SUCCESS;
}
All seams to work fine. But now I recognize that in some modes of my application, specially if BT is switched off, the average current consumption increases from 260uA to 660uA (more than double) with this work-a-round. The current spices looks like the same. In other modes my application draw much more current and that's the reason why I didn't see it before.
Additionally my application calculates the energy consumption and take most of the additional current automatically in account. This mean that a "module" is switched on that my energy calculation knows. E.g. the HFXO is switched on the whole time instead of only a few ms: It could also be more CPU running time. But I have no idea how or what happen.
How can this happen?
How does the softdevice (or SDK) using the function "sd_app_evt_wait()"?
To be clear: if I change the work-a-round back, and only that, I got 260uA again.
Regards,
Dirk
PS SDK V15.2.0 and S132 6.1.1 is used
