[Fwd: Re: [gta02] Fwd: PS: high rate of broken devices even on prodction test. DESIGN BUG!]

Andy Green andy at openmoko.com
Fri Apr 18 09:47:30 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Am Fr  18. April 2008 schrieben Sie, Andy Green:
|> Somebody in the thread at some point said:
|> | Am Fr  18. April 2008 schrieben Sie, Allen Chang:
|> |> Dear All:
|> |>
|> |> I found that if I don't plug the USB (include D+ and D- data) ,
the PMU
|> |> setting will not change in U-Boot.
|> |> I remove U4905 and short the U4905( RT9711)'s VIN and VOUT. I set
U4904
|> |> (AAT1275) to output 5V.
|> |> I set  MBCC7 =3 (suspend) and MBCC8 = 0, the total current doesn't
|> |> still increase
|> |>
|> |> Therefore, using 0 ohm resistor replace U4905 is maybe  a solution.
|> |
|> | If we really can disable USB power_in on PCF50633 by setting the
|> registers to
|> | appropriate value, I think we are better off without RT9711. So kick
|> it off
|> | board and replace it with 0R. Fine!
|>
|> Guys did we secretly understand this problem and I missed it?
|>
|> Something horrible happens to a low percentage of RT9711 Vin protection
|> circuit in the factory.  Maybe the unknown "something horrible" comes
|> and attacks PMU USB pins if we just 0R out the RT9711 and pass it on.
|>
|> I understand the redesign aspect to get rid of the RT9711 and it sounds
|> like a cool idea (if we are sure it is good for all cases like
|> charger)... but we only examine this situation because of chips blowing
|> up connected to that net, and we don't know why and we cannot reproduce
|> it here AFAIK.
|>
|> If we make the change we just hope that somehow the PMU USB inputs are
|> less sensitive than the RT9711 without actually understanding what makes
|> the problem.  Hey we can still do it but that is the case I think.
|>
|> -Andy
|>
|
| Exactly, this probably in no way will solve the problem (unless that's
| oscillation of the RT9711 itself).
| PMU USB_input y no means is more robust than RT9711, the contrary is true.
| However it's no difference at all to have 0.5V or 1.0V for safety
headroom.
| And we are getting rid of useless complexity.
|
| OTOH we well never may find the real reason of the fireworks, if the
failure
| is gone some "magical" way after the 9711->0R change.
| If we still see chips popping, it's not worse than before - just then the
| 50633 blows up instead of the 9711. ;-)

I agree tough to see how to fix it when we didn't see a dead board.  And
I NEVER saw a dead board that I worked on or heard about that failure
mode (it is a very noticable failure mode!  No USB power!) except from
the factory.  So it needs a really unusual condition to make this
trouble I think.

I don't have a better idea than Allen's 0R plan, but it isn't very
satisfying not to understand it.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgIUhIACgkQOjLpvpq7dMpsHwCfespxetWZTYxiuG/R7mUSy899
4+4AnjT7RHtsF2FSjGdbqNwLNIj2ZB8T
=1Xkx
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list