Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

helsing — Fri, 26 Mar 2021 13:42:14 GMT

Thank you for the update. Let us know if this issue cause you any trouble as your project is progressing.

Have a nice weekend.

Best Regards,

Håkon

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

d_c_h_w — Wed, 24 Mar 2021 12:08:36 GMT

I can confirm this works for my application. I am using the method with the ENABLE register directly. Also I see no additional latency either due to the enabling and disabling which is good. I will leave this in my code until there is a more formal fix.

Thanks again for you help

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

d_c_h_w — Wed, 24 Mar 2021 11:02:48 GMT

Thank you for looking into this, I will try your initial workaround and see if I can see the same current drop as yourselves.

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

helsing — Wed, 24 Mar 2021 10:48:22 GMT

Below follows findings about this issue and a proposed temporary workaround. We can confirm different harwdware behaviour between SPI1 and SPI4, and our team is working on a proper workaround.

First, for SPI1, current consumption should also be lower than 40uA. If you add CONFIG_SERIAL=n to prj.conf, then idle should drop to around 3uA(measured in the blinky sample you posted).

When it comes to SPI4, only disabling logging does not help as we are still seeing around 600uA. However, if we comment out SPI_sendData, then the current consumption becomes normal. This shows us the current draw is related to SPI4 and TX.

The following code demonstrates the increased current, and also how it could be minimized.

typedef struct ArrayList
{
    uint8_t buffer[100];
} ArrayList_type;

static ArrayList_type spi_tx[100];
static ArrayList_type * spi_tx_p = spi_tx;
static ArrayList_type spi_rx[100];
static ArrayList_type * spi_rx_p = spi_rx; 

void main(void)
{
    NRF_SPIM4->PSEL.MOSI = 11;
    NRF_SPIM4->PSEL.MISO = 12;
    NRF_SPIM4->PSEL.SCK = 13;
    NRF_SPIM4->RXD.PTR = (uint32_t)spi_rx_p;
    NRF_SPIM4->RXD.MAXCNT = 100;
    NRF_SPIM4->TXD.PTR = (uint32_t)spi_tx_p;
    NRF_SPIM4->TXD.MAXCNT = 100;
    NRF_SPIM4->ENABLE = 7;    
    
    while (1) {
        NRF_SPIM4->ENABLE = 7;
        NRF_SPIM4->TXD.PTR = (uint32_t)spi_tx_p;
        NRF_SPIM4->TXD.MAXCNT = 100;
        NRF_SPIM4->TASKS_START = 1;
        k_msleep(100);

        NRF_SPIM4->TASKS_STOP = 1;
        NRF_SPIM4->ENABLE = 0;
        k_msleep(500);
    }
}

The code sets up an SPI transaction every 600ms. After it starts, it waits 100ms, then runs ENABLE=0. This makes the device go back to a "normal" idle and it now draws 3uA.

If one remove ENABLE=0, then the current draw stays at 700uA in idle(which it, of course, should not).

So, the temporary proposal is to disable SPI after the transaction. I could get back to you regarding the best way to do this in harmony with the driver. It might be either to use the ENABLE register directly after the transaction, or perhaps, to use the driver's uninit function.

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

helsing — Tue, 23 Mar 2021 15:32:58 GMT

We have reproduced the issue on two boards. We are working on some theories and will keep you updated.

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

helsing — Tue, 23 Mar 2021 11:28:09 GMT

Hi Dominic, I will give you an update later today.

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

d_c_h_w — Mon, 22 Mar 2021 11:56:32 GMT

Hi helsing, have you managed to take a look into this yet

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

helsing — Fri, 12 Mar 2021 19:59:25 GMT

Thank you very much for providing the code and detailed description. I am looking discussing this with the team and will get back to you next week.

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

d_c_h_w — Wed, 10 Mar 2021 17:16:28 GMT

I have modified the simple binky sample on an nRF5340-DK using the 1.5.0 SDK version
I erased the flash first so there is nothing running on the network core
To trigger the extra idle current it just takes a single spi tx using SPI4
The code is set to use spi4 currently, to change back to spi1, 3 files need to be changed

1) Change '&spi4' to '&spi1' in nrf5340dk_nrf5340_cpuapp.overlay
2) Change 'CONFIG_SPI_4=y' to 'CONFIG_SPI_1=y' in prj.conf
3) Change SPI_DEVICE_NAME so that it references spi1 instead of spi4 in main.c

Sorry, I probably could have made this easier with a KConfig option.

If switching SPI interfaces in an active project, as project files have changed you need to then do:
Project->Reload 'blinky'
Project->Run Cmake
Build->Build and Run

On this particular project, with SPI4 interface active I see 750uA idle, but only 126uA idle with SPI1

Hope this helps you reproduce the issue

devzone.nordicsemi.com/.../4846.blinky.zip

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

d_c_h_w — Wed, 10 Mar 2021 15:44:38 GMT

Hi, no it is our own application, I don't believe there any samples that use spi in the SDK.

I will try and craft a simple example using one of the samples, as I don't think you have to actually send any spi traffic to trigger the higher base load.

RE: Increased idle current draw in nRF5340 when SPI4 chosen over SPI1

helsing — Wed, 10 Mar 2021 15:34:13 GMT

Hi Dominic,

I will be taking a look at this and check if anyone in our team has seen similar things.

I will also try to reproduce the issue. Is your application based on a sample?