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

joerg at openmoko.org joerg at openmoko.org
Fri Apr 18 09:24:12 CEST 2008


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. ;-)

cheers
jOERG







More information about the openmoko-kernel mailing list