[Fwd: Re: [gta02] Fwd: PS: high rate of broken devices even on prodction test. DESIGN BUG!]
andy at openmoko.com
Fri Apr 18 09:47:30 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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) ,
|> |> setting will not change in U-Boot.
|> |> I remove U4905 and short the U4905( RT9711)'s VIN and VOUT. I set
|> |> (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.
| 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
| And we are getting rid of useless complexity.
| OTOH we well never may find the real reason of the fireworks, if the
| 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel