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

[m.wagner]

I've been checking the nRF52805 Errata document to see which errata apply to our product and do not yet have a workaround implemented in our firmware.

Unfortunately, I'm not sure what to make of #246.

Symptoms
Extra current consumption in the range of 350 µA when in System On Idle.

Conditions
A high-speed peripheral (CPU for example) accesses a RAM block which is being accessed by a low-speed
peripheral through the DMA bus, with a specific timing, and the high-speed peripheral has higher priority
than the low-speed peripheral.

Consequences
Extra current consumption in System On Idle.

What is the definition of a "high-speed peripheral" vs. a "low-speed peripheral"? Can you categorize the peripherals into these two categories?

From what I gather, this applies to EasyDMA-Peripherals - specifically in our product we use the RADIO and SAADC peripherals - and of course the CPU... So as I understand it, the conditions are given that the error described could occur in our product. Is this right?

When exactly is the current consumption increased?

• Does it increase just for the duration where the conditions are prevalent?
• Does it increase once the conditions are met and then stay as high?
• Is current consumption only high for one time going into System On IDLE after the condition occurred?

Furthermore, is there a sensible way to proactively prevent said condition when using RADIO and/or SAADC?

I would be glad if you could help me out here. It's hard to evaluate the power hit this induces from the description alone.

Best regards,

- mike

[Stian Røed Hafskjold]

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.

[m.wagner]

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

[Stian Røed Hafskjold]

m.wagner said:

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?

 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.

 

m.wagner said:

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

 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.

[m.wagner]

Okay, thank you very much.

[hmolesworth]

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.