Errata 89 vs nRf52840 chip revisions

[Anders Esbensen]

Hi 

I have been struggling with increased power consumption after SPI slave usage, and finally seems to have found a solution, based on errata 89.

However looking through the errata's this issue is marked fixed from Engineering version B.

The chip on my evaluation board says 

N52840

CKAAD0

20448T

As far as i can see this should be a revision 2 chip, and as a result i would expect the issue described in the errata  to be fixed.

Is Errata 89  is still relevant in my case ?

[Vidar Berg]

Hi,

The idle current should be around ~400 uA if you encounter this errata. Does that correspond with what you are measuring,  or is it only in 10-20 uA range? The latter could be the SPIS idle current. The errata workaround is effectively disabling the SPIS.

Best regards,

Vidar

[Anders Esbensen]

Hi

Yes the excess current is ~400 uA and applying the workaround fixes the issue.

But according do documentation this workaround should not be necessary for newer chip revisions, since the Errata 89 has been marked fixed ?

However it seem too still be relevant for SPIS mode.

Br Anders

[Vidar Berg]

Hi Anders,

I think there must be a different root cause for the issue you are seeing even though the suggested workaround solves the problem. SPIS was not one of the affected peripheral according to the errata description, and I don't recall seeing this problem before either.

Anders Esbensen said:

However it seem too still be relevant for SPIS mode.

Agree. It seems like the SPIS keeps requesting the HF clock source until you apply the errata workaround. Are you using any other peripherals which share the same peripheral ID as your SPIS instance : Instantiation , Peripherals with shared ID ?

Best regards,

Vidar

[Anders Esbensen]

Hi Vidar

I use TWIM0 , TWIM1, and SPIS2, so I expect no conflict between those.

When i see the increased power consumption it is typically after the SPI master (host) is powering down with SPIS on the nRF still active.  So my guess is that the SPIS is entering transaction mode when SPI pins go low, and ends up in a state where the HF clocks remain active even after nrfx_spis_uninit call.

Most post in this forum as related to SPIM, so this might be a different variant of the issue.

[Vidar Berg]

Hi Anders,

Anders Esbensen said:

So my guess is that the SPIS is entering transaction mode when SPI pins go low, and ends up in a state where the HF clocks remain active even after nrfx_spis_uninit call.

This probably explains it. SPIS starts requesting the HF clock as soon as the chip select pin is asserted. But it should have been possible to disable the module while the CS was active.

I think it should ok to use the errata 89 workaround to get around this limitation.