• State Not Answered
  • Replies 11 replies
  • Subscribers 69 subscribers
  • Views 447 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328677
Options

nrf5340 sleep currrent consumption

Lavanya_Manohar

In our custom board nrf5340-nrf7002, tried system_off(C:\ncs\v2.6.1\zephyr\samples\board\nrf )sample to check power consumption. 

But it measures 0.60mA

Is there any config need to address? please provide debug steps

Parents Reply Children
  • 0 in reply to Priyanka

    Hi Priyanka,
    Thank you for your support.

    Somehow we manage and reduced the current measurement in our board. Below are the current consumption measurements and challenges we are facing:

    • Current Consumption:

      • nRF5340: ~30 µA in sleep mode.
      • nRF7002: ~2 µA in idle mode (shut down during sleep).
      • We are working on further reducing the nRF5340's current consumption.

    • Application Details:

      1. Wi-Fi module is set to idle and shut down during sleep.
      2. Console/UART is suspended before entering idle mode.
      3. SPI/external flash is suspended before entering idle mode.
      4. I2C is suspended before entering idle mode.
      5. A Counter Timer is used for periodic wakeups.

    • Issue:
      The nRF5340 sleep current documentation indicates consumption as low as ~5 µA in many scenarios. However, we are seeing 30 µA, which seems higher than expected.
      Could you please clarify this?

    • Debugging Observations:
      We measured voltage on various pins during sleep and observed:

      • COEX-related pins, IOVDD, HOST IRQ, and QSPI pins show voltages ranging from 1V to 3.3V.

    Could this be causing the higher current consumption? If so, what steps can we take to mitigate this?

    • Request for Suggestions:
      We would need your guidance on:
      1. Understanding the expected sleep current for nRF5340 in this scenario.
      2. Eliminating potential issues related to COEX and other pin voltages.
      3. Any additional steps to optimize current consumption further.
  • 0 in reply to Lavanya_Manohar

    Hi,

    Are you using the COEX related pins? If you are not using them, then it's better to configure them as disconnected inputs in the dts or explicitly set as inputs with no pull resistors in your application.

    Make sure there are no floating pins. Also make sure that the external flash is in a deep sleep mode. Also make sure that the IOVDD is not connected to any unused GPIO pins. Try to set all unused GPIO pins to disabled and try not to leave them floating. 

    If you still have current issues, maybe you could try to isolate the current readings on 5340 and 7002 to see which causes the extra leakage. You can also to check the current measurements on each CO-EX related pins to see which has a spike.

    -Priyanka

  • 0 in reply to Priyanka

    Hi Priyanka,
    Thank you for you response.

    Priyanka said:
    Are you using the COEX related pins? If you are not using them, then it's better to configure them as disconnected inputs in the dts or explicitly set as inputs with no pull resistors in your application.

    We are using both BLE and Wifi, so COEX is needed right?

        nrf_radio_coex: nrf7002-coex {
            status = "okay";
            compatible = "nordic,nrf700x-coex";
            req-gpios = <&gpio0 28 GPIO_ACTIVE_HIGH>;
            status0-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;
            grant-gpios = <&gpio0 24 (GPIO_PULL_DOWN | GPIO_ACTIVE_LOW)>;
            swctrl1-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>;
            btrf-switch-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;

    We     };

    Above coex configuration is in zephyr.dts file

    Priyanka said:
    make sure that the external flash is in a deep sleep mode.
    We put external flash in suspend mode.
    pm_device_action_run(spi_flash_dev, PM_DEVICE_ACTION_SUSPEND)

    Could you please suggest how can we acheive the deep sleep mode?


Related