Poor iMX7D power performance

cancel
Showing results for 
Search instead for 
Did you mean: 

Poor iMX7D power performance

1,797 Views
jacobpostman
Contributor II

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

Labels (2)
14 Replies

665 Views
ericnelsonaz
Contributor III

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.

665 Views
rubenschwarz
Contributor II

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

0 Kudos

665 Views
cbg1
Contributor II

Hi Eric,

Any updates pls also share?

0 Kudos

665 Views
ericnelsonaz
Contributor III

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.

0 Kudos

665 Views
evgenyerlihman
Contributor IV

Hey Eric,

Do you have any updates regarding your finding?

Thanks,

Evgeny

665 Views
ericnelsonaz
Contributor III

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

0 Kudos

665 Views
jamesbone
NXP TechSupport
NXP TechSupport

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?

0 Kudos

665 Views
jacobpostman
Contributor II

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

0 Kudos

665 Views
jamesbone
NXP TechSupport
NXP TechSupport

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.

 

0 Kudos

665 Views
mooreaa
Contributor II

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

0 Kudos

665 Views
jamesbone
NXP TechSupport
NXP TechSupport

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

0 Kudos

665 Views
jamesbone
NXP TechSupport
NXP TechSupport

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.

0 Kudos

665 Views
bonzo
NXP Employee
NXP Employee

James,

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

brad.stewart@nxp.com

0 Kudos

665 Views
jamesbone
NXP TechSupport
NXP TechSupport

Dear Jacob,

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

0 Kudos