GPIOTE and SPI high power consumption on sleep

RE: GPIOTE and SPI high power consumption on sleep

ColdBrew667 — Fri, 10 Mar 2017 19:29:22 GMT

Thank you so much Stian, this is a mystery resolved! The workaround is working fine.

RE: GPIOTE and SPI high power consumption on sleep

Stian Røed Hafskjold — Fri, 10 Mar 2017 09:25:45 GMT

What has been discussed in the other answers are described in this errata: infocenter.nordicsemi.com/.../anomaly_832_97.html. This should not cause more than 20µA, so I believe this could be related to something else.

There is an errata describing problems with TWI together with GPIOTE: infocenter.nordicsemi.com/.../anomaly_832_89.html. Although the errata only mention TWI, SPI is sharing resources with TWI so same thing could happen with SPI.

So, the bug is in TWI in general. Peripherals sharing resources with TWI0 is TWIS0, TWIM0, SPI0, SPIM0 and SPIS0. Peripherals sharing resources with TWI1 is TWIS1, TWIM1, SPI1, SPIM1 and SPIS1. infocenter.nordicsemi.com/.../memory.html

SPI2 is not sharing resources with a TWI peripheral, so it should not be impacted by this bug.

You can try to use SPI2 instead, or use the workaround provided in the errata and see what happens.

RE: GPIOTE and SPI high power consumption on sleep

ColdBrew667 — Thu, 09 Mar 2017 21:49:03 GMT

I highly doubt that the SPI hardware is at fault. I can reproduce the issue using PCA10040 and spis example as slave for SPI hardware. This example is just echoing back what I am sending and I am sending thing upon button push only. I don't believe that it is related to hardware but more as a combination of execution of the two drivers one after the other. Like SPI is activating an oscillator for clock generation and suspend its usage and then when GPIOTE comes into picture it uses it somehow and lives it running before going to sleep. I will try the port mode but I don't think that it will be a real solution for our whole system.

RE: GPIOTE and SPI high power consumption on sleep

Roger Clark — Thu, 09 Mar 2017 20:27:30 GMT

AFIK the bug was fixed in the nRF52, but as it is such a small change to the code, I suggest you try it.

If changing it does not fix the problem, there are several other options.

Your SPI hardware is taking the power.
Your SPI hardware is constantly generating interrupts.
This problem is not actually related to the SPI

RE: GPIOTE and SPI high power consumption on sleep

ColdBrew667 — Thu, 09 Mar 2017 19:23:13 GMT

I tried this but then the nrf_drv_gpiote_in_init() function comes back with an error 0x0004 (no memory for operation) and I couldn't explain why... Is there something more to do while using this way of doing it?

RE: GPIOTE and SPI high power consumption on sleep

ColdBrew667 — Thu, 09 Mar 2017 19:19:20 GMT

Hello, thank you for your answer but I do not use nRF51 but nRF52. Is this hardware bug still present on this last chip? Moreover, if I am using GPIOTE alone I do not see any power consumption. It is really the combination of SPI and GPIOTE that causes the issue

RE: GPIOTE and SPI high power consumption on sleep

Roger Clark — Thu, 09 Mar 2017 03:53:54 GMT

Just to elaborate

See this question

devzone.nordicsemi.com/.../

Basically there is a problem with the nRF51 hardware, which requires the HF (16Mhz) oscillator to be running to in order for an interrupt on an individual pin to trigger an interrupt.

So you need to use "Port mode" instead but calling

GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);

This mode does not require the HF oscillator to run.

However, in this mode, if you have more than on interrupt input pin, you need to read the value of the pin(s) inside the ISR to confirm which pin has caused the interrupt.

RE: GPIOTE and SPI high power consumption on sleep

Gustavo Velasco-Hernández — Thu, 09 Mar 2017 02:42:53 GMT

use this instead:

nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);

this will set accuracy to low and decrease the power consumption.