SPIM3 draws higher current even with Errata workaround

Hi,

I am using nrf52840-based custom hardware and have an external flash connected on SPIM3. Till now I was working with my other peripheral connected on different buses and was measuring current consumption for all of them to maintain a power budget.

Without enabling flash and SPIM,3 I have reached an Idle current consumption of 80uA. When I enabled the flash on SPIM3, it jumped to 550uA. I saw the errata document for that issue and found that in my ncs version 2.6.1 in nrfx_spim.c has a workaround added for anomaly_195. I confirmed by adding the logs there whether it is executing or not, and found that it is executing.

For testing, I added a while loop in my main which resumes the power of flash, checks the chip id, and after 3 seconds of sleep, it suspends the power and again sleeps for 3 seconds, and this loop continues.

From the logs, I found that my PM APIs are executed successfully, and also checked from the hardware that the clock pin of SPIM is also responding to its states in between the suspend and resume power states.

Can anyone suggest, there is anything that needs to be done apart from this work around which is already present, and still the current consumption is high.

//// Main 
while(1) {
    power_on();
    k_msleep(3000);
    power_off();
    k_msleep(3000);
}

int power_on()
{
    int ret =0;
#ifdef CONFIG_PM_DEVICE
    LOG_INF("Resume Flash peripheral");
    ret  = pm_device_action_run(nand_flash, PM_DEVICE_ACTION_RESUME);

    flash_read_jedec_id(nand_flash,false);
#endif
    return ret;
}

int power_off()
{   
    int ret =0;
#ifdef CONFIG_PM_DEVICE
    LOG_INF("Suspending Flash peripheral");
    ret  = pm_device_action_run(nand_flash, PM_DEVICE_ACTION_SUSPEND);
#endif
    return ret;
}


//// nrfx_spim.c
#if NRFX_CHECK(USE_WORKAROUND_FOR_ANOMALY_195)
    if (p_instance->p_reg == NRF_SPIM3)
    {
        *(volatile uint32_t *)0x4002F004 = 1;
    }
#endif

Parents
  • Hi Ankit,

    You seem to be doing it correct. 

    Even after suspending the SPIM3 peripheral, there is a chance that the state of the SPI pins can affect leakage current, especially if they are left floating or in a state that allows current to flow through the external flash or the SoC's input buffers. So maybe you can try to explicitly drive them low or something. Maybe take a look at this ticket.

    Also, you can try to check that you're sending a real deep power down command to the flash, not just suspending the SPI bus. Also, make sure that the HFCLK is off after the flash is suspended.

    If you have not already done this, in the dts file, you can define "sleep" pinctrl states for your SPI peripheral, which makes sure that the pins are set to a low-power state when the device is suspended. 

    Regards,

    Priyanka

  • Hi Priyanka,

    Thank you for the reply,

    I have identified the issue why the SPIM3 is still on even after disabling it through PM APIs. It was due to the MCU Boot, as I am using MCU Boot with an external flash to store the secondary partition. So when I turned off the MCU boot, I did not see the current flowing due to SPIM3 and I also verified through the ENABLE state of SPI.

    Here, I have two questions. Even after suspending the SPIM3 instance from the application, why is it not getting suspended when I turned on the MCU boot?

    The second question is, when the SPIM3 is enabled, why does it draw that much current, I mean 500uA is too high for an interface?

Reply
  • Hi Priyanka,

    Thank you for the reply,

    I have identified the issue why the SPIM3 is still on even after disabling it through PM APIs. It was due to the MCU Boot, as I am using MCU Boot with an external flash to store the secondary partition. So when I turned off the MCU boot, I did not see the current flowing due to SPIM3 and I also verified through the ENABLE state of SPI.

    Here, I have two questions. Even after suspending the SPIM3 instance from the application, why is it not getting suspended when I turned on the MCU boot?

    The second question is, when the SPIM3 is enabled, why does it draw that much current, I mean 500uA is too high for an interface?

Children
No Data
Related