Poor iMX7D power performance

[jacobpostman]

I am doing a power evaluation on a modified imx7d sabre board and am seeing higher than expected power consumption from the imx7D, both when sitting awake and idle and during suspend to memory.

When ttymxc0 is not set as a wakeup source, the VDD_3V3 current in suspend increases dramatically, while the current on VDD_SOC decreases.

I expect that the imx7d should be able to reach much better power numbers.

The best I can guess right now is that the clock domain configuration is not working as intended. Is this a known issue? Am I barking up the wrong tree and is there anything else in my configuration that I should be looking for?

---

Setup:

Most peripheral components on the imx7d sabre board have been removed and each of the following rails is provided and measured externally.

Only USB OTG, DEBUG UART-USB and a SD card are attached to the board.

I am using a yocto 2.0 machine-test image rootfs with an independently built kernel and dts based from the bsp 4.1.15_1.0.0_ga tree.

All items in imx7d-sdb.dts except for i2c3, sdma, uart1, usbotg1, and usbotg2 are removed or disabled.

Power:

Awake and idle:

VDD_ARM  7.3 mA,   1V     7.3 mW

VDD_SOC 154 mA,   1V     154 mW

VDD_1V8  12.5 mA, 1.8V   22.5 mW

VDD_3V3  15 mA,   3.3V   49.5 mW

VSNVS   <1 mA,   3V     <3 mW

VLPSR   0.05 mA, 1.8V   0.09 mW

Suspend to mem with ttymxc0 set as wakeup source:

VDD_ARM 0.6 mA,   1V     0.6 mW

VDD_SOC 13 mA,   1V     14.3 mW    < Why is this so high?

VDD_1V8  5 mA,     1.8V   9 mW

VDD_3V3  5 mA,     3.3V   16.5 mW

VSNVS   <1 mA,   3V     <3 mW

VLPSR   .05mA,   1.8V   0.09 mW

Suspend to mem without ttymxc0 wakeup source:

VDD_ARM 0.6 mA,   1V     0.6 mW

VDD_SOC 1.3 mA,   1V     1.3 mW

VDD_1V8  5 mA,     1.8V   9 mW

VDD_3V3  61 mA,   3.3V   201.3 mW < Why is this so high?

VSNVS   <1 mA,    3V     <3 mW

VLPSR   .05mA,   1.8V   0.09 mW

Jacob

[ericnelsonaz]

While chasing the code paths taken during suspend, I also found that the extra current is related to this line in gpcv2.c (imx_gpcv2_mf_mix_off()).

The code in question is this:

imx_gpcv2_set_slot_ack(1, FAST_MEGA_MIX, false, false);

If I comment out that line, the 5V current drops by roughly 50mA.

I don't yet know enough about the GPC to interpret this, but it seems that something is wrong here.

[rubenschwarz]

I know, this is an old thread. But is there any outcome on this problem? Any solution?

[cbg1]

Hi Eric,

Any updates pls also share?

[ericnelsonaz]

Hi cbg@yitoa.com,

Sorry, but it's been a long while, and I don't recall how we resolved this.

Perhaps jacobpostman or Kerms recall the outcome.

[evgenyerlihman]

Hey Eric,

Do you have any updates regarding your finding?

Thanks,

Evgeny

[ericnelsonaz]

I've been able to replicate Jacob's findings with an un-modified i.MX7D SABRE SD board.

Measuring the input current to the 5V supply, I found that the current consumption is:

• 296 mA while idle
• 287 mA in suspend to mem without the UART wakeup, and
• 242 mA in suspend to mem with the UART wakeup

This is trivially easy to test with a meter on the input power supply.

To suspend, I'm doing this:

root@imx7dsabresd:~# echo +10 > /sys/class/rtc/rtc0/wakealarm && \
> echo mem > /sys/power/state

And to enable wake, I'm doing this:


root@imx7dsabresd:~# echo enabled > /sys/class/tty/ttymxc0/power/wakeup

[jamesbone]

Hello Jacob,

What kind of changes you made to the i.MX7D Sabre Board?  where are you taking this measurements and can you provide the steps to reproduced it?

and the revision of the board that you are using?

[jacobpostman]

Hi James,

Thanks for the response.

The SABRE board says REV C on it, but uboot detects it as REV B. I looked through the REV B rework instructions and it didn’t look like they would be of concern to me with the reduced functionality that I’m looking for.

The list of rework is as follows:

Depopulate U2 (PERI_3V3 reg, TSSOP)

Depopulate U4 (PF3000, QFN)

Depopulate U42 (PCIE Timer, QFN)

Depopulate U38

Depopulate U13 (HDMI, QFN)

Depopulate U14 (HDMI LDO, SOT)

Depopulate L14 (VDD_WLAN)

Depopulate L15 (WLIO1V8)

Depopulate R329 (VDD_WLCLK36)

Depopulate R311

Depopulate D22

Depopulate U45

Add 2 x 1.5K resistor to create DDR VREF from resistor divider from SW3_1V35

Depopulate D1

Depopulate R33, R34, R61, R62 (I2C PU)

Essentially, removing anything connected to the PERI_3V3 rail, and driving all other rails externally. Current is measured on the feed lines to the following rails:

VDD_ARM, VDD_SOC, VDD_1V8, VDD_3V3, VSNVS, VLPSR, NVCC_DRAM, 5V input to MEM_3V3

Attached is the defconfig and the modified sabre dts.

Thanks!

Jacob

[jamesbone]

Q1:

Suspend to mem with ttymxc0 set as wakeup source:

VDD_ARM 0.6 mA,   1V     0.6 mW

VDD_SOC 13 mA,   1V     14.3 mW    < Why is this so high?

I suspect there is an osc or pll running to allow for the ttymxc0 to act as a wake-up source. Double check the osc and pll's.

Q2: VDD_3V3: Since there is no such label on the chip or on the SABRE board, I am not sure which one to focus on. Please let me know which power rail you are talking about here.

[mooreaa]

Hi James,

I'm replying for Jacob with the information you requested.

Q1. Attached are a list of the clocks that are running prior to when we enter the suspend state. I've generated a version with ONLY the active clocks as well as the script used to generate the output.

Q2: The VDD_3V3 rail is referring to the NVCC_3V3 rail

[jamesbone]

Thanks Aaron,

Your local FAE, the Apps Engineer and myself are reviewing internally your information.  I will let you know or  your local FAE as soon as we got a response

[jamesbone]

Aaron,

Some things that we have identify is that the  it seems that the chip is in system idle and not low power idle. The low power idle should be in the 1.4mW range for VDD_SOC, where the system idle will be running around 19mW range.

[bonzo]

James,

Could you send me your NXP email?  We need to coordinate our efforts.

brad.stewart@nxp.com

[jamesbone]

Dear Jacob,

We are trying to reproduced the issue and reviewing internally once we have a response, we are getting back to you.