SPI Consumption problem

[Cristian]

I'm testing SPIM of nRF52 on PCA10040 using S132 and SDK11.

Its base on the app_peripheral_uart example, so I already have BLE communication.

When SPI is not initiated, current consuption is arround 370 uA, but when adding SPI it goes to 800uA. no matters if its transmitting or not, and theres is no way to came back to previous consuption.

I've been working hard to find a cause, but I really dont see why this is happening. I've debugged and checked SPI is coreclty stopped after TX/RX ends. I'm already using NRF52_PAN_23 define. I've even add uninit function after TX/RX ends, but its still the same.

This is the code I made to handle SPI, based on SPI example from SDK: ( acc_handler() function is called every 3 seconds from a timer based function)

define SPI_INSTANCE  0 

static const nrf_drv_spi_t spi = NRF_DRV_SPI_INSTANCE(SPI_INSTANCE);

static volatile uint8_t spi_xfer_done; 


void spi_event_handler(nrf_drv_spi_evt_t const * p_event)

{

    spi_xfer_done = 1;
    nrf_spim_event_clear(spi.p_registers, NRF_SPIM_EVENT_END);
    nrf_spim_event_clear(spi.p_registers, NRF_SPIM_EVENT_STARTED);
    nrf_drv_spi_uninit(&spi);
}

void init_spi(void)

{

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG(SPI_INSTANCE);
    spi_config.mosi_pin = 25;
    spi_config.miso_pin = 24,//26;
    spi_config.sck_pin = 23,//20;
    spi_config.ss_pin = NRF_DRV_SPI_PIN_NOT_USED;//SPI_CS_PIN;
    spi_config.frequency = NRF_DRV_SPI_FREQ_500K;
    APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, spi_event_handler));
    spi_xfer_done   = 1;
}

uint8_t send_spi(uint8_t *txdata, uint8_t *rxdata, uint8_t len)

{

    if(!spi_xfer_done)
      return(1);
    
    spi_xfer_done   = 0;
    APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, txdata, len, rxdata, len));

    return(0);
}

void acc_handler(void)

{

uint16_t tx, rx;

  tx = 0x55AA;

  init_spi();

  send_spi((uint8_t *)&tx, (uint8_t *)&rx, 2);

}

Is there anything wrong ? Did I miss anything ?

Thanks in advance.

[Ole Bauck]

It sounds like HFCLK is running all the time which leads to a current increase of 400-450uA. When the SPI transaction is done it should release the clock and the current should go down to what it was before the transaction.

Try to only run the SPI code and see if the behavior is the same.

PAN 23 is only present on rev A chips (PCA10036) so no need to worry about that.

[Cristian]

Hi, Thanks for your comments.

I`ve followed your advise and disable everything (except for the timer) and power went down to 30uA. So the first thing I enable again was the advertising, and consumption return to 800uA. I imagine there is some interaction, but I dont know how to fix it. I've tried enabling DCDC and also stopping HFCLK on the interruption routine. (by the way, I've debug CLOCK registers and HFCLK is being disable correctly after transfer ends, with no need to call "sd_clock_hfclk_release()")

Any thoughts?

[Ole Bauck]

Can you try to use SPI instance 2 instead:

#define SPI_INSTANCE  2

and see if the current consumption goes down?

[Cristian]

I've tried changing to SPI2, but consumption changed just 50uA. Then I tried disabling TWI1 from nrf_drv_config.h (being that I already removed any call to twi driver) and now current consuption is as expected !!. Anyway, I could not achieve this current with SPI0. Just SPI1 and SPI2 are correct. I even was able to configure TWI0 without problem. Is there any difference on SPI0? Is there any known conflic between SPIx and TWI1?

[Ole Bauck]

We have seen issues with SPIM0/1 and TWIM0/1 regarding this. The relevant errata for this can be found here. We are still investigating this issue so it does not cover all use cases that will lead to increased current consumption (like using SPIM0/1). When we have more information we will update this issue.

When you say SPIO or SPI1 you mean SPIM0 or SPIM1? We thought this issue was only with the DMA enabled SPI or TWI peripheral (SPIM/SPIS/TWIM/TWIS). It is also strange that you don't see any problem with SPIM1 as this should also cause the current increase (only SPIM2 should not cause the current increase).