Suspended mode

Andy Green andy at
Mon Feb 4 11:09:51 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

> I know what you worry, and I also know this possibility. I try to

Great -- I know this task is not an easy one (especially it is so
difficult to find signals to monitor on the PCB with the tiny packages).

> test some thing in u-boot, because I can change GPIO setting in
> U-boot. I remove B1701 (GSM power path) and the GSM does not have any
> power source .I set GPIO( TX, RX,CTS,RTS,INT0,IO1) to input mode. I
> still found VBAT ( GSM power) have 1.0Voltage. I check all GSM's pins
> connect to any chip (S3C2442,Audio Codec, download buffer).I start
> measuring these pins and I found the RX has 1.8V voltage. It is more
> than VBAT. Therefore, I just assume the RX is the source and I set
> these GPIO to low. The VBAT change to 0.001 V. I don't sure it is

Understood, thanks for the detailed explanation.  I didn't look at this
circuit until now, so please excuse any mistakes from my side.

I guess we talk about signal RX_MODEM, it must be a big clue it is >
Vbat.  But there is no way that the CPU GPIO can generate the voltage,
the GPIO only has pulldown now and if we set it to input the leakage
current is way too small to make this voltage.

I would do two things... first I would try to pull down RX_MODEM by a
known resistance to 0V like 1K or 4K7, and examine the change in voltage
on RX_MODEM.  This tells you the source impedence and it might make a
big clue.  If the source impedence is, eg, 100K, then we should drop
this problem because we won't win anything.  If it is say 2K we can make
a good win on suspend current by fixing this.

The second one we can't easily do with this board.  I would start
cutting tracks on the PCB or lifting pins (ha -- not with these chips)
to isolate the source of the 1.8V.  Who gives the RX_MODEM net the 1.8V?
 It definitely should not be the CPU.  Maybe you can make something like
this test by removing any 0V that are available in series on the supply
rails, eg, R1006, R1003, R1004, R1001.

Also check all the supply rails like V-DBB, V-IO, V-FLASH (hmm), V_SRAM,
V-SIM, V_RTC (hmm) and V-ABB to find ones that have >=1.8V in suspend,
then try to remove any pullup to these rails, eg, if V-SIM has >= 1.8V,
try to remove R1010 as a test.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list