Re: GSENSOR_3V3 voltage drop
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 hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GSENSOR_3V3 voltage drop
[Á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 signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GSENSOR_3V3 voltage drop
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 hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GSENSOR_3V3 voltage drop
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 hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GSENSOR_3V3 voltage drop
2009/8/23 Christoph Mair m...@chonyota.net: 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 hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GSENSOR_3V3 voltage drop
[Á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: 11100110ACK0111ACK10110011ACK1101ACK .. 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 hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GSENSOR_3V3 voltage drop
[Christoph Mair So 23. August 2009]: 2009/8/23 Christoph Mair m...@chonyota.net: 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 hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
