nRF52832 SPI slave: expected idle current?

[JordanYates]

This old question ( nRF52832 SPI Slave Pulls Excessive Idle Current ) raised the issue of excessive power consumption of the SPI slave peripheral compared to the datasheet.
The datasheet has not been updated (Online link) and still states that the expected idle current is 1uA.

The reason I am looking into this is that I have ~40 boards with a nRF52832 BT controller connected to a nRF9160 BT host.
With both SoC's in a low power configuration, the boards consistently idle at ~4.7uA (expected given other parts on the board).
Once the nRF52832 configures a SPIS peripheral (even on physically disconnected pins), half of the boards run at ~10uA, the other half run at ~15uA.

The exact same behaviour occurs if I attempt to configure a GPIOTE channel to trigger on a pin falling edge, as per the following

uint8_t gpiote_ch;

nrfx_gpiote_channel_alloc(&gpiote_ch);
nrf_gpiote_event_configure(NRF_GPIOTE, gpiote_ch, 26,
				GPIOTE_CONFIG_POLARITY_HiToLo);
nrf_gpiote_event_enable(NRF_GPIOTE, gpiote_ch);

I am guessing that internally the SPIS peripheral is making use of GPIOTE to watch the CS pin for transitions, which would account for the same behaviour.

Firstly, I am looking for an "official" answer as to what the expected idle current is when SPIS is enabled but there is no CS activity.
Secondly, I am looking for a reason why I am seeing this 50/50 split in power consumption between boards. Errata 97 could potentially explain it, but only if the "high current consumption" varies between individual parts, and if the SPIS peripheral is actually using GPIOTE internally.

[Håkon Alseth]

Hi,

 

Firstly, I am looking for an "official" answer as to what the expected idle current is when SPIS is enabled but there is no CS activity.

It is as described in the link that you posted, an added current draw similar to that of GPIOTE IN channel usage.

It shall be less than 20 uA.

Secondly, I am looking for a reason why I am seeing this 50/50 split in power consumption between boards. Errata 97 could potentially explain it, but only if the "high current consumption" varies between individual parts, and if the SPIS peripheral is actually using GPIOTE internally.

There are chip-to-chip variances on our devices that can account for smaller differences.

Is the pin(s) itself pulled to a defined level at this point? If not, could you please try to add a pull-resistor on the CS pin?

 

Kind regards,

Håkon

[JordanYates]

Thanks for the input Håkon,

I updated the test case to use a disconnected pin on the SoC, and configuring that pin to have an internal pull-up. This didn't change the results. Some boards 10uA and others 15uA with the code below, all boards 5uA without.

	const struct device *p0 = DEVICE_DT_GET(DT_NODELABEL(gpio0));
	uint8_t gpiote_ch;

	gpio_pin_configure(p0, 6, GPIO_INPUT | GPIO_PULL_UP);

	nrfx_gpiote_channel_alloc(&gpiote_ch);
	nrf_gpiote_event_configure(NRF_GPIOTE, gpiote_ch, 6, GPIOTE_CONFIG_POLARITY_HiToLo);
	nrf_gpiote_event_enable(NRF_GPIOTE, gpiote_ch);

[Håkon Alseth]

Hi,

 

Thank you for confirming, I just wanted to make sure that it was tested without any possible leakage on the GPIOs.

JordanYates said:

This didn't change the results. Some boards 10uA and others 15uA with the code below, all boards 5uA without.

I have double-checked internally, and this is within the expected range. The added consumption will vary from chip-to-chip, but it shall be less than 20 uA in total.

 

Kind regards,

Håkon