NRF52840 Consumption SDK15.2

RE: NRF52840 Consumption SDK15.2

Einar Thorsrud — Tue, 11 Dec 2018 12:57:24 GMT

Hi,

I do not have a strong recommendation. I have not timed the function calls to initialize and reinitialize the SPI driver, but I would expect it to be quite fast. If it is, then I would say that initializing and initializing the driver is probably the best solution as it is cleaner. If not, then your approach by just disabling the GPIO input pin ENABLE register should be OK as well. At least, I do not see that it should cause any problematic side effects.

RE: NRF52840 Consumption SDK15.2

mtorti — Tue, 11 Dec 2018 11:41:10 GMT

Hi,

I think you are right, it must be happening what you are saying. The strange thing is that with nRF52832 we didn't have this problem. So what do you think would be the best workaround? Configure as default the MISO pin every time i disable the SPI and reconfigure it when i enable it?

RE: NRF52840 Consumption SDK15.2

Einar Thorsrud — Tue, 11 Dec 2018 10:28:44 GMT

Hi,

The call to nrf_gpio_cfg_default() configures the GPIO to the default state, which is disconnected input. The fact that this solves the issue is not so strange, as the MISO pin is probably floating (not driven by the slave) when the chip select signal is deasserted. A floating GPIO inputs could very well cause high current consumption if the voltage is in the undefined region.

RE: NRF52840 Consumption SDK15.2

mtorti — Mon, 10 Dec 2018 17:21:03 GMT

Hi,

I investigated the nrf_drv_spi_uninit() and the magic line is nrf_gpio_cfg_default(p_cb->miso_pin);

If i don't use nrf_drv_spi_uninit() function and instead do nrf_gpio_cfg_default(MISO_PIN); NRF_SPI0->ENABLE=0; the consumption decrease to a few uA as expected. if i comment the line nrf_gpio_cfg_default(MISO_PIN) the idle consumption increase too much. Is this normal? What could be causing this?

RE: NRF52840 Consumption SDK15.2

Einar Thorsrud — Mon, 10 Dec 2018 09:24:40 GMT

Hi,

Were you able to find out more about this?

RE: NRF52840 Consumption SDK15.2

mtorti — Thu, 06 Dec 2018 11:07:11 GMT

Hi,

I'm using the SPIM0 with EasyDMA.

The code look like this:

static const nrf_drv_spi_t m_spi = NRF_DRV_SPI_INSTANCE(0);

nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;

spi_config.sck_pin = 12;
spi_config.mosi_pin = P0_PIN_NUM+ 9;
spi_config.miso_pin = 8;
spi_config.ss_pin = 6;

spi_config.frequency = NRF_DRV_SPI_FREQ_500K;
spi_config.mode = NRF_DRV_SPI_MODE_0;
spi_config.bit_order = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST;
spi_config.orc = 0xCC;
spi_config.irq_priority = APP_IRQ_PRIORITY_LOW;

err_code = nrf_drv_spi_init(&m_spi, &spi_config, NULL, NULL);
APP_ERROR_CHECK(err_code);

Then i make some communication with

err_code = nrf_drv_spi_transfer(&m_spi, tx_buf, 2, rx_buf, 2);

and finally:

NRF_SPI0->ENABLE = 0;

I will try to investigate further the nrf_drv_spi_uninit() function to see what is the line that is solving the high consumption.

RE: NRF52840 Consumption SDK15.2

Einar Thorsrud — Thu, 06 Dec 2018 10:29:53 GMT

Hi,

You do not even need to call nrf_drv_spi_uninit(). If you comment it out in the code from the previous post you should still see good power consumption numbers. Can you say more about how you use SPI? Is it SPI or SPIM (with DMA), how is the driver configured, how does you SPI code look like?

RE: NRF52840 Consumption SDK15.2

mtorti — Wed, 05 Dec 2018 14:32:23 GMT

Hi Einar,

Using the nrf_drv_spi_uninit function the consumption decrease to 3uA, so the problem seems to be that NRF_SPI0->ENABLE=0 is not enough to shutdown the SPI.

The only drawback is that our application is relatively time and consumption constraint, we are periodically enabling and disabling the SPI to lower the current and save battery. Already the nrf_drv_spi_uninit adds overhead compared to NRF_SPI0->ENABLE; in addition to this i have to reinitialize the entire SPI when re-enabling it? In the SDK12 NRF_SPI0->ENABLE=0 and NRF_SPI0->ENABLE=1 were enough to enable and disable SPI and get the lowest consumption.

RE: NRF52840 Consumption SDK15.2

Einar Thorsrud — Wed, 05 Dec 2018 13:31:30 GMT

Hi,

What else do you do in your code when you use SPI? You should not see a high current consumption after a SPI transaction. You can verify this by for instance taking the SPI SDK example, disabling UART logging and modifying it so it looks like this (doing a single transaction before going to sleep). There you should get a current is a few micro amps (verified on my side using a nRF52840 DK):

int main(void)
{
    bsp_board_init(BSP_INIT_LEDS);

    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    spi_config.ss_pin   = SPI_SS_PIN;
    spi_config.miso_pin = SPI_MISO_PIN;
    spi_config.mosi_pin = SPI_MOSI_PIN;
    spi_config.sck_pin  = SPI_SCK_PIN;
    APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, spi_event_handler, NULL));

    NRF_LOG_INFO("SPI example started.");

    // Reset rx buffer and transfer done flag
    memset(m_rx_buf, 0, m_length);
    spi_xfer_done = false;
    APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, m_length, m_rx_buf, m_length));

    while (!spi_xfer_done)
    {
        __WFE();
    }

    nrf_drv_spi_uninit(&spi);

    NRF_LOG_FLUSH();

    while (1)
    {
        __WFE();
    }
}

RE: NRF52840 Consumption SDK15.2

mtorti — Tue, 04 Dec 2018 17:01:25 GMT

I verified the code further and it seems that the high consumption is due to the SPI. In the code, i configure the SPI, do some task and then shutdown it with NRF_SPI0->ENABLE = 0, but the consumption does not decrease. If i don't initialize the SPI then the iddle current is 3uA as expected. Is something missing?

RE: NRF52840 Consumption SDK15.2

Einar Thorsrud — Tue, 04 Dec 2018 14:14:22 GMT

Hi,

Most of the BLE examples in the will consume about 2-3 μA out of the box as long as you disable UART logging (enabled by default). We need to look more detailed at your application in order to see what you have such a high idle current consumption. Can you elaborate? also, have you attempted to strip out/disable parts of your application to narrow down what could cause the high current consumption?