GSENSOR_3V3 voltage drop

[Christoph Mair]

Hello,

I have some questions regarding the GSENSOR_3V3 line:
Under normal conditions I measured 2.8V. In suspend, the voltage drops to
2.4V. I thought the the line would carry 3.3V when powered on and ~0V in
suspend. Why isn't that the case?

How much current should I be able to get from this line? I connected the
three-axis magnetometer HMC5843 which works fine when the phone is powered on.
It even takes measurements in suspend, but then the voltage drops down to
1.76V when a measurement takes place (every second for 4ms).

Can someone explain how this is supposed to work?

Thank you,
  Christoph

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[AlvieBoy]

Christoph Mair wrote:

> Hello,
>
> I have some questions regarding the GSENSOR_3V3 line:
> Under normal conditions I measured 2.8V. In suspend, the voltage drops to
> 2.4V. I thought the the line would carry 3.3V when powered on and ~0V in
> suspend. Why isn't that the case?
>
> How much current should I be able to get from this line? I connected the
> three-axis magnetometer HMC5843 which works fine when the phone is powered on.
> It even takes measurements in suspend, but then the voltage drops down to
> 1.76V when a measurement takes place (every second for 4ms).
>
> Can someone explain how this is supposed to work?

Hi Chris,

Although I'm not directly involved in GTA02, I am in gta02-core, and I might be able to answer some of your questions.

GSENSOR_3V3 is generated from one of PMU LDO (LDO1). Output voltage is controlled by software, in 100mV increments. Max. output current from this LDO is 50mA.

Suspend is also defined by software. Typically this would be set to GPIO1 input, which is controlled by CPU (PWREN signal). Maybe someone can confirm this.

This line powers two LIS302DL accelerometers, which draw 0.4mA max each. This gives less than 1mA. This gives enough room for power output, so either your
problem lies in VB_SYS (not enough current to feed the LDOs), a shortened caps (C1718), broken LIS203DL...

What voltage do you see in VB_SYS, on those scenarios ? Can you also check voltahe PMU GPIO1 pin (TP1740) when phone is in suspend mode ?


Best,

Álvaro

>
> Thank you,
>   Christoph
>
> _______________________________________________
> hardware mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/hardware

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Joerg Reisenweber]

[Álvaro Lopes So  23. August 2009]:
> Christoph Mair wrote:
> > Hello,
> >
> > I have some questions regarding the GSENSOR_3V3 line:
> > Under normal conditions I measured 2.8V.

We need to check what's the correct setting for LDO1 voltage, in PMU.
2.8 sounds fishy.

> > In suspend, the voltage drops to  
> > 2.4V. I thought the the line would carry 3.3V when powered on and ~0V in
> > suspend. Why isn't that the case?

ACK.
For suspend I suspect a reverse feed thru SPI_MOSI1 and/or SPI_CLK1 lines
which might be at high (1) level even though LDO1 is powered down. If that's
the case then it needs a fix urgently. Some of he kernel guys need to check
that.
Another more unlikely scenario is suspend reprograms LDO1 out voltage to 2V4.
Even more unlikely seems you overload the powerrail (>50mA) during suspend
only.

> >
> > How much current should I be able to get from this line? I connected the
> > three-axis magnetometer HMC5843 which works fine when the phone is powered
on.
> > It even takes measurements in suspend, but then the voltage drops down to
> > 1.76V when a measurement takes place (every second for 4ms).

That seems to be another indicator for high source-impedance reverse feed thru
SPI_MOSI/CLK

> >
> > Can someone explain how this is supposed to work?

If only I could tell for sure.. ;-D

>
> Hi Chris,
>
> Although I'm not directly involved in GTA02, I am in gta02-core, and I might
be able to answer some of your questions.
>
> GSENSOR_3V3 is generated from one of PMU LDO (LDO1). Output voltage is
controlled by software, in 100mV increments. Max. output current from this
LDO is 50mA.

correct

>
> Suspend is also defined by software. Typically this would be set to GPIO1
input, which is controlled by CPU (PWREN signal). Maybe someone can confirm
this.

I'm not completely convinced about that. Alas we have no generic application
notes for GTA02-hw, so you can only guess what's the supposed way to manage
things. My guess however would be to switch LDO1 down directly via
PMU-register by writing over I2C. The purpose of PWNEN is a little bit cloudy
to me.

>
> This line powers two LIS302DL accelerometers, which draw 0.4mA max each.
This gives less than 1mA. This gives enough room for power output, so either
your
> problem lies in VB_SYS (not enough current to feed the LDOs),

unlikely, FR wouldn't work at all of that was the case I guess.

> a shortened caps (C1718), broken LIS203DL...

hmm, doesn't make a good story with the whole bunch of observed strange
behaviour
>
> What voltage do you see in VB_SYS, on those scenarios ? Can you also check
voltahe PMU GPIO1 pin (TP1740) when phone is in suspend mode ?

/jOERG

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Sven Rebhan]

I assume you are using an andy-tracking kernel!? If this is the case
please apply the patch I sent in

http://lists.openmoko.org/pipermail/openmoko-kernel/2009-August/010483.html

and check if it fixes the problem. Thanks!

    Sven

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Christoph Mair]

Hello Sven,

> I assume you are using an andy-tracking kernel!? If this is the case
> please apply the patch I sent in
>
> http://lists.openmoko.org/pipermail/openmoko-kernel/2009-August/010483.html
>
> and check if it fixes the problem. Thanks!

The voltage is now between 3.32V and 3.44V which seems to be ok, but after
suspending it still drops to 2.44V Vmax and 1.78V Vmin (when the compass chip
starts a measurement).

Btw.: do you know if the I2C controller and all I2C devices get suspended too?
I added some code to my kernel driver for HMC5843 to disable the device on
suspend. As it seems the functions are never called. But this may be a bug in
my code since this is the first kernel driver I ever wrote.

Christoph

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Sven Rebhan]

2009/8/23 Christoph Mair <[hidden email]>:
> The voltage is now between 3.32V and 3.44V which seems to be ok,

Nice.

> but after
> suspending it still drops to 2.44V Vmax and 1.78V Vmin (when the compass chip
> starts a measurement).

Just to make sure I got you right: You enable the "g-sensor" and get about 3.3V,
then you suspend and _while suspended_ you get 2.4V and 1.8V respectively?
What happens when you resume? Do you get back 3.3V? If this is the case you
probably don't set GPD12/13 (CS), GPG7 (CLK), GPG6 (MOSI) to 0 and GPG5 (MISO)
to pulldown during suspend and leak the voltage from the CPU. Can you please
make sure you set those pins during suspend!

Sven

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Christoph Mair]

> 2009/8/23 Christoph Mair <[hidden email]>:
> > The voltage is now between 3.32V and 3.44V which seems to be ok,
>
> Nice.
>
> > but after
> > suspending it still drops to 2.44V Vmax and 1.78V Vmin (when the compass
chip
> > starts a measurement).
>
> Just to make sure I got you right: You enable the "g-sensor" and get about
3.3V,
> then you suspend and _while suspended_ you get 2.4V and 1.8V respectively?
> What happens when you resume? Do you get back 3.3V? If this is the case you
> probably don't set GPD12/13 (CS), GPG7 (CLK), GPG6 (MOSI) to 0 and GPG5
(MISO)
> to pulldown during suspend and leak the voltage from the CPU. Can you please
> make sure you set those pins during suspend!
I switch my Neo on, and the line goes immediately to 3.3V (I'm using Qi, if
that matters). After SHR started (but with andy-tracking-kernel) I take the
first measurement which results in 3.3V. I never explicitely enabled the g-
sensor. Then I suspend the device which results in the voltage drop down to  
2.4 (normally) or 1.8 (only if my chip draws some current, I think 1mA max,
but I did not check this yet).
Right after resuming the voltage rises to 3.3V again.
I never touch the other pins since the compass chip has a I²C interface. I
just use GSENSOR_3V3 as power supply, because it is easily accessible at
C7802.

Christoph

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Christoph Mair]

> [Álvaro Lopes So  23. August 2009]:
> > Christoph Mair wrote:
> > > Hello,
> > >
> > > I have some questions regarding the GSENSOR_3V3 line:
> > > Under normal conditions I measured 2.8V.
>
> We need to check what's the correct setting for LDO1 voltage, in PMU.
> 2.8 sounds fishy.
FIxed with kernel patch. Now i get ~3.4V which seems to be ok.

> > > In suspend, the voltage drops to  
> > > 2.4V. I thought the the line would carry 3.3V when powered on and ~0V in
> > > suspend. Why isn't that the case?
>
> ACK.
> For suspend I suspect a reverse feed thru SPI_MOSI1 and/or SPI_CLK1 lines
> which might be at high (1) level even though LDO1 is powered down. If that's
> the case then it needs a fix urgently. Some of he kernel guys need to check
> that.
> Another more unlikely scenario is suspend reprograms LDO1 out voltage to

2V4.
> Even more unlikely seems you overload the powerrail (>50mA) during suspend
> only.

<snip>

> > Suspend is also defined by software. Typically this would be set to GPIO1
> input, which is controlled by CPU (PWREN signal). Maybe someone can confirm
> this.
>
> I'm not completely convinced about that. Alas we have no generic application
> notes for GTA02-hw, so you can only guess what's the supposed way to manage
> things. My guess however would be to switch LDO1 down directly via
> PMU-register by writing over I2C. The purpose of PWNEN is a little bit
> cloudy to me.
There is some communication on the I2C bus approx. 13ms before the voltage
drop. The last message starts with:
11100110<ACK>00000111<ACK>10110011<ACK>11111101<ACK> ..
0x6E, 0x07, 0xB3, 0xFD ..
And is therefore addressed to the PMU. I can try to decode the rest, if it may
be useful.
(The actual decoding was done in my head, so there may be some bit errors ;) )

> > This line powers two LIS302DL accelerometers, which draw 0.4mA max each.
> This gives less than 1mA. This gives enough room for power output, so either
> your
> > problem lies in VB_SYS (not enough current to feed the LDOs),
>
> unlikely, FR wouldn't work at all of that was the case I guess.
>
> > a shortened caps (C1718), broken LIS203DL...
>
> hmm, doesn't make a good story with the whole bunch of observed strange
> behaviour
> >
> > What voltage do you see in VB_SYS, on those scenarios ? Can you also check
> voltahe PMU GPIO1 pin (TP1740) when phone is in suspend mode ?

I will check the voltage at TP1704 now.
 
Christoph

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Christoph Mair]

> Christoph Mair wrote:
> > Joerg Reisenweber wrote:
> > [Álvaro Lopes So  23. August 2009]:
> > > This line powers two LIS302DL accelerometers, which draw 0.4mA max each.
> > This gives less than 1mA. This gives enough room for power output, so
either

> > your
> > > problem lies in VB_SYS (not enough current to feed the LDOs),
> >
> > unlikely, FR wouldn't work at all of that was the case I guess.
> >
> > > a shortened caps (C1718), broken LIS203DL...
> >
> > hmm, doesn't make a good story with the whole bunch of observed strange
> > behaviour
> > >
> > > What voltage do you see in VB_SYS, on those scenarios ? Can you also
> > > check voltahe PMU GPIO1 pin (TP1740) when phone is in suspend mode ?
>
> I will check the voltage at TP1704 now.

Voltage on TP1704 during normal operation: 3.44V
during suspend: 120mV
The accelerometers aren't broken, altishock works perfectly :)

Christoph

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Joerg Reisenweber]

[Christoph Mair So  23. August 2009]:

> > 2009/8/23 Christoph Mair <[hidden email]>:
> > > The voltage is now between 3.32V and 3.44V which seems to be ok,
> >
> > Nice.
> >
> > > but after
> > > suspending it still drops to 2.44V Vmax and 1.78V Vmin (when the compass
> chip
> > > starts a measurement).
> >
> > Just to make sure I got you right: You enable the "g-sensor" and get about
> 3.3V,
> > then you suspend and _while suspended_ you get 2.4V and 1.8V respectively?
> > What happens when you resume? Do you get back 3.3V? If this is the case

you
> > probably don't set GPD12/13 (CS), GPG7 (CLK), GPG6 (MOSI) to 0 and GPG5
> (MISO)
> > to pulldown during suspend and leak the voltage from the CPU. Can you

please
> > make sure you set those pins during suspend!

^^^^!

> I switch my Neo on, and the line goes immediately to 3.3V (I'm using Qi, if
> that matters). After SHR started (but with andy-tracking-kernel) I take the
> first measurement which results in 3.3V. I never explicitely enabled the g-
> sensor. Then I suspend the device which results in the voltage drop down to  
> 2.4 (normally) or 1.8 (only if my chip draws some current, I think 1mA max,
> but I did not check this yet).
> Right after resuming the voltage rises to 3.3V again.
> I never touch the other pins since the compass chip has a I²C interface. I
> just use GSENSOR_3V3 as power supply, because it is easily accessible at
> C7802.

As suspected in my other posting, and explained by Sven, the GSENSOR_3V3 rail
may see "phantom"-feeding by the data(MOSI)/clk-lines if those are at 3V3
while LDO in PMU is powered down, during suspend. It doesn't matter if *you*
touch those lines, the feeding may take a path thru the gmeters (the clamp
diodes there) so you see some voltage of 3V3 - (voltage-drop on diode).
Please check as suggested by Sven

cheers
/jOERG

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Christoph Mair]

> [Christoph Mair So  23. August 2009]:
> > > 2009/8/23 Christoph Mair <[hidden email]>:
> > > > The voltage is now between 3.32V and 3.44V which seems to be ok,
> > >
> > > Nice.
> > >
> > > > but after
> > > > suspending it still drops to 2.44V Vmax and 1.78V Vmin (when the
compass
> > chip
> > > > starts a measurement).
> > >
> > > Just to make sure I got you right: You enable the "g-sensor" and get
about
> > 3.3V,
> > > then you suspend and _while suspended_ you get 2.4V and 1.8V
respectively?
> > > What happens when you resume? Do you get back 3.3V? If this is the case
> > > you probably don't set GPD12/13 (CS), GPG7 (CLK), GPG6 (MOSI) to 0 and
> > > GPG5 (MISO) to pulldown during suspend and leak the voltage from the
> > > CPU. Can you pleasemake sure you set those pins during suspend!
>
> ^^^^!

> As suspected in my other posting, and explained by Sven, the GSENSOR_3V3
rail
> may see "phantom"-feeding by the data(MOSI)/clk-lines if those are at 3V3
> while LDO in PMU is powered down, during suspend. It doesn't matter if you
> touch those lines, the feeding may take a path thru the gmeters (the clamp
> diodes there) so you see some voltage of 3V3 - (voltage-drop on diode).
> Please check as suggested by Sven
GPD12/13 (G1_CS and G2_CS) remain high (3V3) after suspend. This probably
leaks current into G1/2_INT and SPI_MISO1 which are at 2V4.

Christoph

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Sven Rebhan]

2009/8/24 Christoph Mair <[hidden email]>:
> GPD12/13 (G1_CS and G2_CS) remain high (3V3) after suspend.

I assume you mean it stays high while _in_ suspend? This is really
strange, as the last action when suspending the accels is:

s3c2410_gpio_setpin(pdata->pin_chip_select, 0);
s3c2410_gpio_setpin(pdata->pin_clk, 0);
s3c2410_gpio_setpin(pdata->pin_mosi, 0);
/* misnomer: it is a pullDOWN in 2442 */
s3c2410_gpio_pullup(pdata->pin_miso, 1);

Which is exactly what we want. However, I don't see how the
chip_select (GPD12 and GPD13) can be high then... Are you really sure
you don't mess with them in your driver? If not, please also post your
findings (GPD12+GPD13 high during suspend) to the openmoko-kernel
mailing list, as there are more capable kernel guys. ;-)


Sven

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Werner Almesberger]

Christoph Mair wrote:
> The voltage is now between 3.32V and 3.44V which seems to be ok,

It seems a little high for a nominal 3.3 V, but it's within range.

By the way, the accelerometers should be okay at a lower voltage:
the chip has a valid supply voltage range of 2.16 to 3.6 V, with
2.5 V being the typical voltage. We couldn't go as low as 2.5 V,
because we'd then violate the VDD_IO+0.3 V limit on the I/O pins,
but a voltage as low as 3.0 V would be acceptable.

The 2.8 V you measured initially would be too low, causing current
to leak through the clamp diodes on the I/O lines during normal
operation.

If we're now operating at a hopefully constant ~3.3 V, it would be
interesting to see if this has an effect on the accuracy of
acceleration measurements. I wouldn't be surprised if it did.

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Werner Almesberger]

Joerg Reisenweber wrote:
> The purpose of PWNEN is a little bit cloudy to me.

It's basically the hardware mechanism the CPU uses to ask for power.
So if there's a rail the CPU needs to operate and that rail is turned
off during suspend, such as CORE_1V3, then it must be switched via
PWREN.

For anything else, you can use I2C. (If the usage pattern coincides
with PWREN, then you can of course also set it to follow PWREN.)

- Werner

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware

[Christoph Mair]

> Sven wrote:
> 2009/8/24 Christoph Mair <[hidden email]>:
> > GPD12/13 (G1_CS and G2_CS) remain high (3V3) after suspend.
>
> I assume you mean it stays high while in suspend? This is really
> strange, as the last action when suspending the accels is:
>
> s3c2410_gpio_setpin(pdata->pin_chip_select, 0);
> s3c2410_gpio_setpin(pdata->pin_clk, 0);
> s3c2410_gpio_setpin(pdata->pin_mosi, 0);
> /* misnomer: it is a pullDOWN in 2442 */
> s3c2410_gpio_pullup(pdata->pin_miso, 1);
>
> Which is exactly what we want. However, I don't see how the
> chip_select (GPD12 and GPD13) can be high then... Are you really sure
> you don't mess with them in your driver? If not, please also post your
> findings (GPD12+GPD13 high during suspend) to the openmoko-kernel
> mailing list, as there are more capable kernel guys. ;-)

To verify my measurements I did:
- remove my own HW which could probably leak current
- reboot the phone to be sure my driver is not loaded (btw. it does never
touch gpio lines, just basic i2c stuff)
- check for autoloaded modules:
        none
- check kernel version:
        uImage-moredrivers-GTA02_andy-tracking-197d20a357d6a884.bin (including 3V3-
patch)
- switch the phone on: GPD12/13 go high
- press the power switch and wait until the phone has suspended:
        GPD13 remains at high level, the voltage drops from 3.4V to 3.28V at G2_CS
        GPD12 seems to be down
        SENSOR_3V3 drops to 2.4V
- press the power switch again to resume the phone:
        G1_CS rises to 3.40V
        G2_CS rises to 3.40V
        SENSOR_3V3 rises to 3.38V

I'm quite sure that yesterday, during suspend, G1_CS was high too. Today I
could not verify this, but G2_CS is definitively high during suspend.

Christoph

_______________________________________________
hardware mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/hardware