NRF52840 Consumption SDK15.2

[mtorti]

Hi,

We have many projects based on nRF52832 SDK 12 and we are porting them to nRF52840 SDK15.2 to take advantage of the new BLE5 features.

The problem is that we are having troubles with the nRF52840 consumption. When idle, our old projects in SDK12 consumed a current of about 2-3 uA. The best we can do with SDK15.2 in 52840 is about 180 uA.

I think the problem is in the configuration, since the SDK15.2 is pretty confusing and not as simple as SDK12. We have many erratic behaviors, specially with the clocks modules. For example, if i don't init the timer module with app_timer_init() the consumption raises about 500uA. 

For reference, our projects use the advertising and scan modules, app_timer and the SPI.

Do you have a good template that is proven to consume 2 or 3 uA when idle, to start with? Do you have any tip of what are we probably doing wrong in the configuration?

Thanks in advance.

[Einar Thorsrud]

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?

[mtorti]

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?

[mtorti]

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.

[Einar Thorsrud]

Hi,

Were you able to find out more about this?

[mtorti]

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?

[Einar Thorsrud]

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.

[mtorti]

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? 

[Einar Thorsrud]

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.