Verdin AM623 - deep sleep configuration and power consumption verification

Technical Support
, , ,
1

Dears,

I’m working on the Verdin AM623 S 512MB WB IT V1.2A.

This is the manifest of the BSP and other layers in use (aligned to latest Toradex manifest repo, updated to yocto scarthgap 7.4.0):

<project name="bitbake.git" path="layers/openembedded-core/bitbake" remote="oe" revision="1c9ec1ffde75809de34c10d3ec2b40d84d258cb4" upstream="2.8"/>
  <project name="meta-openembedded.git" path="layers/meta-openembedded" remote="oe" revision="e621da947048842109db1b4fd3917a02e0501aa2" upstream="scarthgap"/>
  <project name="meta-yocto" path="layers/meta-yocto" remote="yocto" revision="82602cda1a89644d1acbe230a81c93e3fb5031c8" upstream="scarthgap"/>
  <project name="openembedded-core.git" path="layers/openembedded-core" remote="oe" revision="4cf131ebd157b79226533b5a5074691dd0e1a4ab" upstream="scarthgap"/>


  <project name="meta-toradex-bsp-common.git" path="layers/meta-toradex-bsp-common" remote="tdx" revision="bf9b67ca1dae378c612ba9fc89e491a11b314e05" upstream="scarthgap-7.x.y"/>

  <project name="meta-toradex-nxp.git" path="layers/meta-toradex-nxp" remote="tdx" revision="5aaa24b977db19e5096ade3e0258db19933aba16" upstream="scarthgap-7.x.y"/>

  <project name="meta-toradex-ti.git" path="layers/meta-toradex-ti" remote="tdx" revision="0e50c759b1e509c2b97b305916702acad3a7f734" upstream="scarthgap-7.x.y"/>

  <project name="meta-freescale-3rdparty.git" path="layers/meta-freescale-3rdparty" remote="githf" revision="70c83e96c7f75e73245cb77f1b0cada9ed4bbc6d" upstream="scarthgap" replace="true"/>

  <project name="meta-freescale-distro.git" path="layers/meta-freescale-distro" remote="githf" revision="b9d6a5d9931922558046d230c1f5f4ef6ee72345" upstream="scarthgap" replace="true"/>

  <project name="meta-freescale.git" path="layers/meta-freescale" remote="githf" revision="62423c69631d7f7cffe2bd20997412d76caa94ef" upstream="scarthgap" replace="true"/>

To test properly the power consumption of the SoM itself versus the 5V input power, we are using the Verdin Development Board V1.1F, and measure the shunt resistor between TP21 and TP22 as per documentation, ratio is 100 (1mV = 100mA).

Using a simple, minimalistic device tree as:

/dts-v1/;

#include "k3-am625.dtsi"
#include "k3-am62-verdin.dtsi"
//#include "k3-am62-verdin-wifi.dtsi"

 / {
     model = "Datamars Midrange Indicator";
     compatible = "datamars,midrange-indicator",
                  "toradex,verdin-am62-wifi-dev",
                  "toradex,verdin-am62-wifi",
                  "toradex,verdin-am62",
                  "ti,am625";
 };


/dts-v1/;


#include "k3-am625.dtsi"
#include "k3-am62-verdin.dtsi"

 / {
     compatible = "datamars,midrange-indicator",
                  "toradex,verdin-am62-wifi-dev",
                  "toradex,verdin-am62-wifi",
                  "toradex,verdin-am62",
                  "ti,am625";
 };



/* ===== Power-prune overrides for deep sleep testing ===== */

/* Keep console UART alive for monitoring */
&main_uart0 {
    status = "okay";
    /delete-property/ wakeup-source;
};

/* Disable Wi‑Fi/BT (SDIO + UART5) */
&sdhci2 {
    status = "disabled";
};
&main_uart5 {
    status = "disabled";
};

/* Disable Ethernet MAC + PHY */
&cpsw3g {
    status = "disabled";
};
&cpsw_port1 {
    status = "disabled";
};
&cpsw_port2 {
    status = "disabled";
};
&cpsw3g_mdio {
    status = "disabled";
};

/* Ensure Ethernet regulators power down in suspend */
&reg_1v0_eth {
    regulator-state-mem {
        regulator-off-in-suspend;
    };
};
&reg_1v8_eth {
    regulator-state-mem {
        regulator-off-in-suspend;
    };
};

/* Disable USB connector node and force VBUS off in suspend */
&{/connector} {
    status = "disabled";
};
&reg_usb0_vbus {
    regulator-state-mem {
        regulator-off-in-suspend;
    };
};

/* Tame eMMC host (disable CQE to allow full suspend) */
&sdhci0 {
    disable-cqe;
};

In the sdk configuration, the flags related to power management are set:

CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_PM_SLEEP=y

Anyway, as we send the command to go in deep sleep

echo mem > /sys/power/state

we see on multimeter the drop from 2.2mV to 0.9mV. That means, 90mA power consumption in deep sleep of the module that is too high.

It is clear that the disable of the peripherals in the device tree overlay itself is not enough to cut all the non required power sources.

How can we get a clue of which modules are not properly switched off?

Is there a set of already known instructions or console commands that must be executed before giving the command to go in deep sleep?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

High Power Consumption in Deep Sleep Mode - Verdin AM62

Your power consumption of 90mA during deep sleep is indeed higher than expected. The issue you’re experiencing is documented and relates to specific limitations of the Verdin AM62 V1.2 SoM during Deep Sleep mode.

Understanding the Deep Sleep Limitation

The Verdin AM62 V1.2 has known limitations with peripheral control during Deep Sleep mode (1). During this mode, the output buffers of GPIO pins are disabled, placing the pins in a High-Z state (1). To preserve the GPIOs’ state, the SoC’s internal pull-up and pull-down resistors (ranging from 15 kΩ to 30 kΩ) are enabled (1). This can cause voltage shifts that may lead to unexpected peripheral behavior (1).

Furthermore, the limitation affects the signal CTRL_SLEEP_MOCI#, which hinders the BSP’s ability to drive this signal properly (1).

Power Management States Overview

According to the Verdin Family Specification, during Sleep state, the CPU is in a low power suspend state and peripherals on the module are either turned off or put in a sleep state (2). The CTRL_SLEEP_MOCI# is driven low, allowing carrier board peripherals that don’t need to be powered in sleep mode to be turned off (2).

Recommended Solutions

  1. Use an I2C GPIO Expander: An I2C GPIO expander can be used as an alternative solution to drive the peripherals’ reset and power-gating GPIOs during the Deep Sleep state (1).

  2. Signal Buffering: The CTRL_SLEEP_MOCI# pin already has a 100k pull-down resistor installed on the module (1). For better reliability, this signal can be buffered with a logic buffer IC (1).

  3. Calculate Voltage Drops: You should estimate the output voltage on the I/O pins under worst-case conditions, considering the internal 30kΩ pull-up or pull-down resistor (1). Based on these calculations, select peripheral components with suitable I/O voltage thresholds and low pin bias currents (1).

Additional Considerations

When selecting external load resistor values, keep in mind that bias current on peripheral IC inputs can flow in both directions, leading to significant voltage drops when the AM62 SoC is in reset state and peripherals stay powered on (1).

For more detailed information on this topic, refer to the AM62 Deep Sleep IO Considerations documentation and the Verdin AM62 Errata/Known Issues section (1).

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

The power consumption have been measured on the Verdin devkit, isolating every pin by setting to “open” each related jumper.

We will check for sure the status of HW peripherals on the carrier board, but now we focus on the SoM module itself decoupled from any other external peripheral.

4

We’ve continued the anlaysis, still without reaching a good result. Here are reported the activities done to investigate and test.

Boot Script Customization (MCC_CQE function disabling)

  • Investigated the origin of boot.scr and confirmed it is sourced from boot.scr-verdin-am62 via IMAGE_BOOT_FILES.

  • Overrode the default boot script by manually generating boot.scr-verdin-am62 using a custom boot.cmd to append the args:

    • env set appendargs ‘quiet splash mmc_core.cqe=0 no_console_suspend ignore_loglevel’

      mmc_core.cqe=0 is needed to override the inability to disable the CQE function that “may” keep the eMMC driver alive during deep sleep, no_console_suspend ignore_loglevel are set to keep console alive after wake up, anyway ignored

  • Replaced @@KERNEL_IMAGETYPE@@ and other template variables with actual values (Image, booti, etc.).

  • Verified runtime boot parameters via /proc/cmdline.

Kernel Image Handling

  • Switched from Image.gz to uncompressed Image to avoid inflate() errors during boot.

  • Set KERNEL_IMAGETYPE = “Image” in local.conf.

  • Ensured Image is included in the boot filesystem via IMAGE_BOOT_FILES.

Device Tree Configuration

  • Created a custom DTS (dm-midrange-indicator.dts) with targeted overrides:

    • Disabled unused peripherals: Wi-Fi (SDIO/UART5), Ethernet (MAC/PHY), USB, and unused regulators.

    • Disabled CQE for eMMC to allow full suspend.

    • Defined a single GPIO (mcu_gpio0_7) as the exclusive wake-up source.

    • Removed wakeup-source from UART to prevent unwanted resume triggers.

Runtime Power Management Verification

To validate the system’s suspend behavior and identify which components remain active during deep sleep, the following runtime diagnostics were performed directly on the target.

Power Domain Status: pm_genpd_summary

Command executed:

cat /sys/kernel/debug/pm_genpd/pm_genpd_summary

Purpose: This file lists all power domains managed by the kernel, their current status (on or off), and the devices associated with each domain.

Excerpt from output:

Codice

pd:57     on       /devices/platform/bus@f0000/fa10000.mmc
pd:78     on       /devices/platform/bus@f0000/601000.gpio
pd:77     on       /devices/platform/bus@f0000/600000.gpio
pd:146    on       /devices/platform/bus@f0000/2800000.serial
...
pd:13     off-0
pd:53     off-0
pd:105    off-0
...

Interpretation:

  • Most domains are correctly powered down (off-0) during suspend.

  • However, some domains remain active, notably:

    • pd:57 → eMMC controller (fa10000.mmc)

    • pd:146 → UART console (2800000.serial)

    • pd:77/78 → GPIO controllers (601000.gpio, 600000.gpio)

These active domains likely prevent the SoC from reaching its lowest power state.

Clock Activity: clk_summary

Command executed:

cat /sys/kernel/debug/clk/clk_summary

Purpose: This file shows all clocks in the system, their enable count, frequency, and which devices are using them.

Excerpt from output:

Codice

clk:146:0   1   1   0   48000000   ...   2800000.serial
clk:57:6   1   1   0   200000000   ...   fa10000.mmc
clk:77:0   1   1   0   125000000   ...   600000.gpio
clk:78:0   1   1   0   125000000   ...   601000.gpio

Interpretation:

  • These clocks are enabled and actively driving their respective peripherals.

  • Confirms that UART, eMMC, and GPIO are not entering clock-gated or low-power states during suspend.

  • This contributes to the observed ~80 mA current draw in deep sleep.

Wakeup Source Verification: wakeup_sources

Command executed:

cat /sys/kernel/debug/wakeup_sources

Purpose: Lists all kernel-registered wakeup sources, their activity counters, and whether they can currently trigger a resume.

Output:

Codice

name                  active_count  event_count  wakeup_count  ...
gpio-keys             0             0            0
alarmtimer.3.auto     0             0            0
2b1f0000.rtc          0             0            0
tps65219-pwrbutton... 0             0            0
mmc0                  0             0            0

Interpretation:

  • gpio-keys is present and configured as the only active wakeup source (via DTS).

  • RTC (2b1f0000.rtc) is present but not active — no wakeup-source property.

  • No other peripherals (e.g., eMMC, PMIC) are configured to wake the system.

This confirms that only the defined GPIO pin (mcu_gpio0_7) can trigger resume, as intended.

Suspend/Resume Testing

  • Successfully entered deep sleep via echo mem > /sys/power/state.

  • Resume works via GPIO trigger.

  • Application launches correctly after boot.

Tests outcome

  • Despite correct DTS and boot configuration, the system does not reach minimal power levels.

  • UART and eMMC remain active during suspend, likely preventing full retention or off mode.

  • Power consumption remains at ~80 mA in deep sleep measured on the Verdin Dev Board (NOT carrier).