0
\$\begingroup\$

I am building a microSD to USB adapter using the Microchip USB2244 IC. The device is in a miniPCIe form factor and communicates via USB to the host which is an embedded platform that runs on batteries.

I found that when idle (no SD access), the device's battery life went from 4hr 53min to 3hr 51min. It seems strange to me that my adapter uses so much battery life when idle, so I was wondering if anyone knows if there's something I can do to improve the power usage.

Update: I did some more tests. The device has a 2210mAh battery. With a generic USB microSD adapter connected, the difference in 2 hours of idle (screen on, no activity) use gave a difference of 75mAh in remaining battery. That means there's an average difference of 38mA with and without the USB device.

With my adapter though, the difference was about 121mA so I think that the host does not support USB suspend mode--the USB2244 uses 110mA while active in full speed and I think the generic USB adapter uses a chip that's more power efficient.

But what's strange is that in another test, I made sure the device is completely powered off (the host keeps the USB port powered even if the device is off) and found that 528mAh was used in a span of 8 hours. Since normally the host can last months powered off, this means the average of 66mA was completely due to my adapter. I know there's no USB activity when the device is powered on, so it should be in suspend mode, right?

If it helps, I've attached the schematics below.

Schematics

\$\endgroup\$
7
  • \$\begingroup\$ hm, what's "much" power usage to you? When you do the math, how much energy (in Wattseconds==Joule, or watthours, or whatever) is drained? If you're after power optimization, going over the comparatively high-voltage, high-power USB interface to connect something to a controller doesn't make much sensen, imho... \$\endgroup\$
    – Marcus Müller
    Jun 19, 2017 at 7:06
  • \$\begingroup\$ Especially since you can't tell whether the power is spent in the USB2244 or the USB host, which must periodically query the bus (it's its job). \$\endgroup\$
    – Marcus Müller
    Jun 19, 2017 at 7:11
  • \$\begingroup\$ How did you measure the time durations you refer to? \$\endgroup\$
    – Andy aka
    Jun 19, 2017 at 7:31
  • 1
    \$\begingroup\$ Have you tried an available SD to USB adapter and looked what happend to battery life with that plugged in? It might well be an issue with the USB configuration on the host side (e.g. no USB power down on idle devices). All USB devices should support a suspend mode, and in that mode the consumption is below 1 mA, so less than 5 mW. And that should not reduce your run time by an hour. \$\endgroup\$
    – Arsenal
    Jun 19, 2017 at 9:44
  • 1
    \$\begingroup\$ In your schematics, the RESET function is implemented poorly. This kind of RC-delayed RESET is only good for bus-powered SD-reader dongles, when 5V comes and goes through plugging into a port. In embedded environment the RESET should be either generated from some PGOOD from main supply, or from a separate voltage monitor-supervisor, or via dedicated GPIO under firmware control. \$\endgroup\$
    – Ale..chenski
    Jun 20, 2017 at 21:23

1 Answer 1

Reset to default
1
\$\begingroup\$

When "no SD access", it doesn't mean that USB is in SUSPEND state. Even if no access, the SD is still mounted and USB bus is active, clocks are running, current is consumed in all communication layers.

To get power saving in "idle" mode, the port (where USB2244 device is attached) must be forced into SUSPEND state. It means that the any traffic must be terminated by host, and then the USB2244 conteroller will enter into low power state (350 uA typical from 3.3V) after 3-ms bus idle time.

More, there is a caveat: even if the 2244 controller goes to SUSPEND, the attached SD card might still consume idle current, unless its power supply is completely turned OFF. For this purpose the 2244 has a built-in FET power switch, which turns SD power off when entering SUSPEND state. If the card is designed that the SD power is not supplied from this switch, power savings might be seriously reduced.

Without SUSPEND state the 2244 controller will consume up to 80-100 mA, and obviously drain your battery.

\$\endgroup\$
7
  • \$\begingroup\$ Thanks, do you think there could be an issue with my regulator? I'm using MIC5219-3.3YM5-TR which is a LDO. I've been told that linear regulators use more power than switching regulators, but would the difference be noticeable? \$\endgroup\$
    – Yifan
    Jun 20, 2017 at 16:16
  • \$\begingroup\$ @Yifan, during development, you should have a development board with means to measure all currents to all parts, and you should identify places where the unwanted current is going. MIC5219 has quiescent current of 8 uA max, and is very unlikely to cause any problem. You still failed to mention any actual current values, nor capacity of your battery. With only relative measurement of battery life it is difficult to determine the root of your problem. \$\endgroup\$
    – Ale..chenski
    Jun 20, 2017 at 18:12
  • \$\begingroup\$ Thanks, I've added more information to the original post. \$\endgroup\$
    – Yifan
    Jun 20, 2017 at 19:25
  • 1
    \$\begingroup\$ @Yifan, you can check if your 2244 chip really goes into suspend by checking VDD18PLL pin voltage. In SUSPEND this voltage should go down, and XTAL oscillations should stop. If not, there must be some unwanted activity on D+/D- lines. \$\endgroup\$
    – Ale..chenski
    Jun 20, 2017 at 20:49
  • 1
    \$\begingroup\$ @Yifan, no, this is impossible. What happens is that when your host is down, both D+ and D- are down. On USB, this is an active state "USB_RESET" for the device, that's why the 2244 is active waiting for USB to finish bus RESET and go idle (D- low, D+ high, no SOF traffic). If/when idle happens, the 2244 will do into SUSPEND. You need to shut down your LDO to avoid this "fake USB reset". \$\endgroup\$
    – Ale..chenski
    Jun 21, 2017 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.