SPIS consumption

[agusuyu]

Hello,

We are using the SPIS on the nRF52832. We are seeing a higher than expected consumption when it's enabled and not used.

I measure around 7uA extra when enabling, which goes away if I disable it.

The ports are properly driven from the master. Am I doing something wrong? The spec says it should be 1uA, not 7.

I reduced the code to the one below, just commenting or not the Disable line.

 spis_init();
 NRF_SPIS1->ENABLE = (SPIS_ENABLE_ENABLE_Disabled << SPIS_ENABLE_ENABLE_Pos);

 for (;;)
    {
        idle_state_handle();
    }

[agusuyu]

Does anyone see the same thing?

My latest test was to check if it's the "interrupt" on CS.

I'm trying with the example pin_change_int and I get the same current consumption. Could this be it? Even though according to the spec it should be <1uA.

[Stian Røed Hafskjold]

Hi, When the SPIS is waiting for an interrupt in the CS pin, the power consumption is similar to the GPIOTE IN event. You can try to trigger on the GPIOTE PORT event instead, and enable the slave in the interrupt handler.

[agusuyu]

So I can't leave the SPIS enabled and use the interrupt? That's basically not using it as intended.

I'd need a PORT event, then enable SPIS and wait for its interrupt, and then disable it.  Is that it?

From the spec GPIOTE shouldn't draw that much current, or should it?

[Stian Røed Hafskjold]

Sorry, but it's a symptom of this errata: https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev2%2FERR%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_97.html&anchor=anomaly_832_97

You can use SPIS as intended, but then you need to accept the additional ~6uA. If that's unacceptable, you can try to use the PORT event instead.

So yes, trigger on PORT event with the CSN line, then enable SPIS, and disable it after it's done.