[Gta04-owner] Modem off

Dr. H. Nikolaus Schaller hns at goldelico.com
Sun Sep 15 10:29:48 CEST 2013

Am 15.09.2013 um 00:29 schrieb NeilBrown:

> On Sat, 14 Sep 2013 18:11:29 +0200 Radek Polak <psonek2 at seznam.cz> wrote:
>> Hi,
>> i wonder if modem powering off works as it should. Attached is charging graph 
>> taken from my GTA04.
>> You can see power consumption for:
>> 1/ normal suspend 13:09 to 14:26, discharging current is 24mA
>> 2/ suspend when modem was turned off as documented here [1] from 14:32 to 
>> 16:11, discharging current is 37mA
>> 3/ device turned off with modem turned off from 16:11 to 16:59, discharging 
>> current is 14mA
>> What is strange - i'd expect current at 2/ to be under 24mA and it should tell 
>> us how much modem eats.
> Clearly the modem actually generates current (harvested from the air waves)
> and when you turn it off, you no longer benefit from that :-)

This is the best explanation!!!
So we should charge the battery that way :)
Who is writing a driver? := :=

> I've noticed this too.  I blame the USB interface.  I'm not really sure why,
> but my current theory is that is it the source of all our problems.

Maybe including the reenumeration thing...

> I've found that if I hold the reset line of the USB transceiver down so the
> chip stays in reset, something eats even more power.
> I'm wondering if that is some way to power down the USB interface in the OMAP
> and hope that reduces power leakage.

I have checked with the USB332x data sheet and here are my findings:

"In USB audio mode, a switch connects the DP pin to the SPK_R pin, and another switch connects he DM pin to the SPK_L pin. These switches are shown in the lower left-hand corner of Figure 5.1. The USB3320 can be configured to enter USB audio mode as described in Section 6.5.2. In addition, these switches are on when the RESETB pin of the USB3320 is asserted. The USB audio mode enables audio signalling from a single USB port of connection, and the switches may also be used to connect Full Speed USB from another transceiver onto the USB cable."

But we have the SPK_* pins unconnected.

"When (RESETB) low, the part is suspended with all ULPI outputs tri-stated. When high, the USB3320 will operate as a normal ULPI device, as described in Section 5.5.2. The state of this pin may be changed asynchronously to the clock signals. When asserted for a minimum of 1 microsecond and then de-asserted, the ULPI registers are reset to their default state and all internal state machines are reset."

Well, such a situation may interfere with the OMAP ULPI/EHCI driver, but I don't see how it makes a difference of 15 mA

Standby Mode RESETB = 0 VVBAT = 4.2V VDD18 = 1.8V VDDIO = 1.8V
IDD33(RSTB)	18	uA
IDD18(RSTB)	0.6	uA

So it should be 19 uA.

There is one thing I can't really estimate from the data sheet: they assume VBATT=4.2V. But we operate the chip from the 3.3V rail. I.e. the VBAT/VDD3.3 line may have lower voltage than VIO (1.8V). So there *may* be some reverse current, unless the chip is protected against this situation (which I would assume).

"The REFCLK can be run at anytime the RESETB pin is low without causing the USB3320 to start-up or draw current."

Ok, but I assume that we stop the REFCLK during suspend.

"The Link is not required to assert the RESETB pin. A pull-down resistor is not present on the RESETB pin and therefore the Link must drive the RESETB pin to the desired state at all times (including system start-up) or connect the RESETB pin to VDDIO."

Ok, this may be a (or the) problem if the OMAP3 is NOT actively pulling down the RESETB line during suspend. The chip will remain enabled and waiting for control through PHY and draw some mA and may even get into some unintended state. And it may respond to the modem which assumes that it can wake up the CPU through USB.

Conclustion: we MUST make sure to assert RESETB during the whole suspend phase.

"The ULPI interface will start operating after the VDD18 and VDDIO supplies are applied and the RESETB pin is brought high. The RESETB pin must be held low until the VDD18 and VDDIO supplies are stable. If the Link is not ready to interface the USB3320, the Link may choose to hold the RESETB pin low until it is ready to control the ULPI interface."

Ok, this indicates that we may operate the chip with 1.8V only (i.e. no 3.3V supply because they are not mentioned).

Table 5.3 gives a quite clear confirmation.

"Section 6.3 Low Power Mode..."
there are some hints how to save power from disabling weak pullups/pulldowns, but I don't think this can make 15mA since they are rated 55-77 kOhm. And even if we assume 15 of them at 1.8V this makes ~0.4 mA potential savings.

Now to the GTM601 modem.

We must make sure that there is no leakage current on any of the interface pins.

I *think* that if we properly suspend the USB interface, the modem does not send voltages (e.g. a 3.3V "i-am-here" signal) on the D+ and D- lines. And even if it does, the counterparts on the USB3322 are in high-impedance state. There are test points for the D+ and D- on the Modem side directly aside of the microphone soldering points where we could verify this during suspend.

* PCM interface.
This means that we must make sure that McBSP4 AND the TWL4030-Voice input are disabled and have no pull-up enabled.
But since the OMAP pullups are also in the 50kOhms range, This can not sum up to more than 1mA.

Finally, I had verified long time ago the 3-10 mA current specified in the GTM601 data sheet by completely powering off the OMAP. You can enter this state by enabling the modem and doing a Linux or U-Boot poweroff. U-Boot also guarantees that there is nothing initialized in the EHCI/USB-PHY section because it's code does not do anything.

But this is not even the case we are discussing. We are discussing the strange power increase if we completely power off the modem through GPIO186 and then suspend the CPU.

So I can only come to the same conclusion that the EHCI within the OMAP is not aware of a "disappeared" USB3322 and therefore does not suspend properly.

And, I have to revise my statement about leakage currents. If the McBSP4 and the TWL-PCM drivers are not disabled but fully powered during suspend (i.e. not just driven high by weak pullups) they can provide 2mA (or even more) leakage current into the inputs of the powered down modem.


More information about the Gta04-owner mailing list