When / how does nRF52805 Erratum 246 "System: Intermittent extra current consumption when going to sleep" exactly apply?

RE: When / how does nRF52805 Erratum 246 "System: Intermittent extra current consumption when going to sleep" exactly apply?

m.wagner — Thu, 01 Jul 2021 09:01:40 GMT

This sounds feasible if IRQs are disabled. A statement from Nordic on this would be useful. Unfortunately, I think they won't be notified of responses to questions with verified answers, therefore I opened a new question concerning this workaround.

Thank you!

Possible alternative workaround for Erratum 246: "System: Intermittent extra current consumption when going to sleep"

RE: When / how does nRF52805 Erratum 246 "System: Intermittent extra current consumption when going to sleep" exactly apply?

hmolesworth — Wed, 30 Jun 2021 15:41:06 GMT

As an improved workaround for errata 246 could we simply precede the __WFE() with a __DSB()? This would ensure no high-speed CPU memory access is in progress (including no stack access) and any peripheral 16MHz accesses are then safe to occur during execution of WFE thereby removing the conditions for the bug.

#define __WFE() __ASM volatile ("wfe")
// Ensure all explicit memory accesses before this instruction complete
#define __DSB() __ASM volatile ("dsb 0xF":::"memory")
  
ENABLE_WAKEUP_SOURCE -> SEVONPEND -> DISABLE_INTERRUPTS -> __DSB -> __WFE -> WAKEUP inside __WFE -> ENABLE_interrupts -> WAKEUP_SOURCE_ISR

Note the __DSB() should be redefined as a macro and not the current inline function definition which may not execute as desired under some compiler settings; a non-inline function call would mess up the intent of this workaround with an unwanted memory-accessing stack pop.

Edit: If running code from RAM instead of FLASH an __ISB() should probably be added immediately before __DSB(); this does not apply to cache I don't think as that is separate memory.

RE: When / how does nRF52805 Erratum 246 "System: Intermittent extra current consumption when going to sleep" exactly apply?

m.wagner — Wed, 30 Jun 2021 13:24:58 GMT

Okay, thank you very much.

RE: When / how does nRF52805 Erratum 246 "System: Intermittent extra current consumption when going to sleep" exactly apply?

Stian Røed Hafskjold — Wed, 30 Jun 2021 13:23:37 GMT

[quote user="m.wagner"]With the workaround enabled, does the extra current consumption occur constantly while the the 16MHz bus is active or also intermittently, in cases where otherwise higher current consumption would have resulted?[/quote]

It will always occur when the 16MHz bus is active. This is typically during transactions when the RAM is updated with the incoming peripheral data, using DMA.

[quote user="m.wagner"]How is this workaround able to shut down the 16MHz clock?[/quote]

This is very complex and I can't share the details, but the workaround does not shut down the 16MHz clock, it just removes one of several conditions necessary to trigger this bug.

RE: When / how does nRF52805 Erratum 246 "System: Intermittent extra current consumption when going to sleep" exactly apply?

m.wagner — Wed, 30 Jun 2021 12:24:04 GMT

Hi Stian,

Thanks for the clarification. In that case I will enable the workaround.

I agree, that this does not seem to be very noticeable while the 16MHz bus is active.

With the workaround enabled, does the extra current consumption occur constantly while the the 16MHz bus is active or also intermittently, in cases where otherwise higher current consumption would have resulted?

How is this workaround able to shut down the 16MHz clock?

Best regards,

mike

RE: When / how does nRF52805 Erratum 246 "System: Intermittent extra current consumption when going to sleep" exactly apply?

Stian Røed Hafskjold — Wed, 30 Jun 2021 12:18:09 GMT

Hi, sorry if you think the errata is confusing. The short story is that the workaround should always be enabled, and I'm not sure why it's not part of the MDK already, leaving it non-optional. I will have to investigate that.

The workaround only results in a worst case of 40 uA extra current consumption on top of the 16MHz bus current, which is already in the 1 mA range, and only when the 16MHz bus is active. So you will barely notice it.

The high-speed vs low-speed phrasing is because of the DMA bus, which has a fast side and a slow side. The fast side refers to the CPU, and the slow side refers to all other peripherals using the 16MHz bus and DMA. I agree that this is not very obvious.

The increased current is due to the 16MHz clock not being released after use by the peripheral. A very specific set of conditions on the bus are necessary for this to happen, so it's very unlikely to happen. The symptom is that the current consumption stays high after the peripheral usage, and will stay high during the system ON idle period, until the next DMA transaction, which will then release the clock. For example, if you set up regular sampling on the SAADC, the current may increase to 350 uA after one sampling event, and stay high until the next sampling event. It happens intermittently, without any way for the application to know.