My Gta02s wont charge / chgena = 0 by default

Andy Green andy at
Thu Jun 26 13:56:30 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> | thing that hints at a problem is that INT4.lowsys is set after
|> | the sudden shutdown.
|> Wouldn't this get set as a symptom of the shutdown, not a cause?
| I'm kinda curious about that myself :-) My current understanding
| is that Vsys shouldn't drop merely as a consequence of going into
| Standby, and that power that is cut in Standby is cut at the
| regulators. (Otherwise, STBYCTLx != 0 wouldn't be possible.)

Sure, but if Vsys did get forced off, you will probably see a lowsys
action.  I agree it shouldn't get forced off legitimately as far as we know.

|> I wonder if what it is doing as part of the charging action is removing
|> the load from the battery so it can assess the voltage on it.  This
|> would "have consequences" if there was no external power.
| That's a different scenario. The one that's causing these problems
| is:
| - charger disabled
| - (sufficient) USB power
| - no or weak battery (still have to determine what is "too weak")
| The system can stay in this state indefinitely. But as soon as I
| enable the charger, it dies quickly (within tens of milliseconds
| if not faster).

Any chance it is a false high temp interrupt?  p42 of the datasheet
talks about the (unused) temp sensing stuff being able to force pcf to
SAVE state if the interrupt isn't responded to in 1s -- we didn't have
interrupt handler in U-Boot last I looked.  The way the temp thing is
apparently set up you'll see different "temp" vs NTCSW pin which is
"controlled by the MBC" p92.

| So what I'll do is to look at Vsys directly (wish we had it on a
| test pad), and to capture the timing with more accuracy (i.e.,
| oscilloscope, not multimeter).

I did this some months ago when I found the lack of capacitor on Vsys
:-)  There were periods of nothingness in there as I recall.

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


More information about the openmoko-kernel mailing list