-----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-----
