Dragonboard power measurements

dustin · July 28, 2017, 9:27pm

I’ve been looking for a solution to get the dragonboard to operate from a suspend state in order to support a battery powered application. I’ve read through the posts related to previous power measurements and found some discussions of suspend software limitations. My current observations involve removing the R108 resistor and installing wire leads to a Tek DMM. I’m only interested in the power consumption of the core SoC and memory and not the other peripherals so this measurement point seems to give a pretty good approximation of this (minus any I/O current to the peripherals). I’ve tried both the latest Linaro Debian 17.06 (https://builds.96boards.org/releases/dragonboard410c/linaro/debian/17.06/) and Android 16.06 (https://builds.96boards.org/releases/dragonboard410c/qualcomm/android/16.06/) builds and looked at idle states and suspend states. Alas, the results have been fairly disappointing. The measurements reflect the ‘idle’ state of the image where only the default services are running. Load averages show nearly nothing running so the CPU’s should spending most time in the WFI state. For both tests the GPS and wifi chip are disabled.

Linaro Debian 17.06 - idle 155mA, suspend to ram not supported, freeze - 130mA, . It appears that suspend state is still not supported in the debian kernel image and that freeze doesn’t really shut much off other than the main CPU’s.

Qualcomm Android 16.06 - idle 105mA, suspend 90mA, freeze not tested. The idle state reflects holding the the adb wakelock (with a usb cable) to prevent the system from entering suspend. When this is removed the kernel log reports that it is entering suspend mode after some idle period as expected under android. However the sleep current is an order of magnitude higher than what I previously measured for an MSM8960 design. I have to conclude that the SoC is not really sleeping and that the DRAM is still active.

I’m just wondering if my measurements line up with what is expected since it seems like really poor performance and rules out any battery operation. Do either the latest CAF or AOSP version’s do a better job of suspend under android? Does anyone know what is missing to do a real suspend?

ljking · August 2, 2017, 7:22pm

Hi @dustin

The 410c board was not designed for minimal suspend current, it was designed for minimal cost. Not all of the circuits get shut down when the board is ‘sleeping’. As an example:The USB Hub is always powered up, and is linear regulated from the 3.7V (always on, and there is no way to switch it off, 20mA). The ADV7533 DSI to HDMI bridge chip is never powered down and it is also powered from the core supply, so it is always drawing power (about 50mA). The USB Hub and the ADV7533 are most of your power consumption.

It may be possible to change the software to power down the ADV7533, but the current Android and Linux builds do not power it down. The current Linux software has very little power optimization (still on the todo list) so I would expect the Android builds to do better.

You need to go through all of the components on the board to find what is still powered up and actually drawing power, it is not necessarily the chipset drawing the power. Other things to look at , LEDs, I2C pull up resistors, every GPIO needs to be set to low current, battery ID circuit, battery thermistor, SDCard, MIPI-DSI switch, etc.

Due to the design, you will not be able to achieve the minimum possible power consumption on the 410c board, you will need to design a custom board.

Full Disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinion of my employer.