This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

High sleep current with SPI reading accelerometer

Using SDK15.3 and S140

following from my previous support request regarding TWI sleep current, I got the newer AIS2DW12 accelerometer and I have successfully connected it with SPI instead of TWI. 

When power profiling I see occasional high sleep current of ~215uA compared to ~22uA expected. I tried to attached the exported PPK2 power profiler output to this report but the upload tool refuses to upload it (it's ~7MB)

Here's some screenshots to let you see what I mean. 1 minute chart. The tall spikes are the SPI reads every 800ms.

Here's a zoom in. As you can see the sleep current is sometimes quite high. (~215uA)

And sometimes much lower ~21uA

This is Breadboarded with an NRF52840 Dongle with AIS2DW12 evaluation board. (https://www.st.com/content/st_com/en/products/evaluation-tools/solution-evaluation-tools/sensor-solution-eval-boards/steval-mki206v1.html)

Dongle has QIAAC0 marking and NRF_FICR->INFO.VARIANT = "AAC0". So I think this is release 1. I also have NRF52840 dongles here that are AAD0 which I could try.

My spi is default except

spi_config.frequency = NRF_DRV_SPI_FREQ_8M;

spi_config.irq_priority = APP_IRQ_PRIORITY_HIGH;(APP_IRQ_PRIORITY_HIGH = 2) 

I needed to set the IRQ to 2 because the SPI calls occur in my timer handler.

All SPI calls are synchronous at the moment. 

static uint8_t * AIS2DW12_readRegisters(uint8_t reg, uint16_t read_length, uint8_t *values) 
{
    uint32_t  err_code;

    spi_tx_buffer[0] = reg | 0x80;    // top bit set = read register

    spi_xfer_done  = false;
    err_code = nrf_drv_spi_transfer(&m_spi, spi_tx_buffer, 2, values, read_length + 1);

    if (NRF_SUCCESS == err_code)
    {
      while (spi_xfer_done == false) ;//printf("S3");   

      return &values[1];    // The first byte is garbage received while we send the register | 0x80 byte
    }
}

I use SPI instance 1 because I also use TWI instance 0. 

const nrf_drv_spi_t m_spi = NRF_DRV_SPI_INSTANCE(SPI_INSTANCE_ID);

I've tested NRF_DRV_SPI_FREQ_8M and NRF_DRV_SPI_FREQ_4M but there was no obvious difference. It seems to sleep with high (~215uA) current around a third of the time.

I started looking at errata but I didn't notice one that specifies SPI1. There may be something else going on

I also found this (https://devzone.nordicsemi.com/f/nordic-q-a/59717/nrfx_spim-driver-causes-high-power-consumption)

and this (https://devzone.nordicsemi.com/f/nordic-q-a/42145/spim-easydma-to-increase-power-consumption)

I tried disabling SPI1_USE_EASY_DMA but it made no difference

I don't use GPIOTE and it is disabled in my sdk_config.h  NRFX_GPIOTE_ENABLED 0 and GPIOTE_ENABLED 0

Have you any idea what the problem could be?

Any help is greatly appreciated.

Parents
  • I've changed to the newer revision NRF52840 Dongle but it's the same power profile.

    My method of stopping SPIM1 is to call  nrf_drv_spi_uninit(&m_spi) after my last call to nrf_drv_spi_transfer.  (after waiting for spi_xfer_done)

    Is this the correct method? I cannot see the implementation to check what it does.

    When I look in the NRF52840 product spec at 6.25.5 I see this

    Should I instead use the ENABLE register?

    I assumed that when using the nrf_drv_spi_ calls then I shouldn't need to touch the registers directly.

    I tried polling TASK_STOPPED with this code but it was always zero

    while (!NRF_SPIM1->EVENTS_STOPPED)     printf ("X");

    I also tried setting ENABLE = 0 after calling uninit but it didn't make any difference.

      nrf_drv_spi_uninit(&m_spi);
    
      NRF_SPIM1->ENABLE = 0;

  • I've noticed it was a bit random whether it was high or low so I suspected it was related to the final bit being received from the accelerometer.

    If I add a completely unnecessary call to write a byte of zeros to an otherwise unused register on the accelerometer (Z_OFS_USR) then I get almost consistently low sleep current

    If I read the WHO_AM_I register then I get high sleep current 100% of the time

    Also, if I unplug the accelerometer from the PPK2 and give it power separately then I see consistently low sleep current.

    So at the moment, I think this is not nrf52 related. It's the accelerometer somehow.

Reply
  • I've noticed it was a bit random whether it was high or low so I suspected it was related to the final bit being received from the accelerometer.

    If I add a completely unnecessary call to write a byte of zeros to an otherwise unused register on the accelerometer (Z_OFS_USR) then I get almost consistently low sleep current

    If I read the WHO_AM_I register then I get high sleep current 100% of the time

    Also, if I unplug the accelerometer from the PPK2 and give it power separately then I see consistently low sleep current.

    So at the moment, I think this is not nrf52 related. It's the accelerometer somehow.

Children
Related