Investigating the iPod USB charging bug

[NiHaoMike]

http://www.rockbox.org/tracker/task/8802

I plan to investigate that iPod USB charging bug using the equipment available in my home electronics lab. I plan to measure current drawn by the 5v input and observing how its behavior changes when I make changes to the code. I will not, however, take apart the iPod unless I absolutely have to for debugging.

For the record, my homemade charging cradle uses 12v so that bug doesn't really bother me. However, my objective is to help other users.

Does anyone know where I can get more detailed hardware documentation?

[saratoga]

You should probably go on IRC and ask Torne about this.  Hes put some effort into it already.

[torne]

There is not really any investigation needed; we know how the iPod behaves when different things are connected, and we know how to change the charging current level. It's not actually a bug, it's a missing feature. The patch attached to FS#8802 works fine for users who know what they're doing: if you enable the setting, it will charge at full speed from any source, PC or AC adapter. The problem is that this is not spec compliant or necessarily safe: it will do so even when the PC has *explicitly told it not to*, or when attached to a non-AC-powered accessory which may not be able to provide that much power.

I am in the process of reworking the USB charging code (for all platforms) so that a "better" setting is available, which lets users choose between no charging, charging when this can be done in a way which is guaranteed to be safe (which will work for PCs but may not work for all AC adapters) or forced charging regardless of charger detection. Once this is done, I will add the code from FS#8802 so that this works on the iPods.

I just haven't had time to finish this work yet. Once I have, then I would be very glad if you could test it using any charging sources you have and a bench meter; but until then, there's not much to be done with the kind of thing you are talking about - right now it's a matter of working out what sensible practises are, by reference to USB specs and established behaviour of other devices.

[NiHaoMike]

What about make it an option in the menu for now? Have it default to the current value, but make it an option for users to manually enable it without going through the trouble of compiling firmware. Add in the autodetect feature later.

I think the current "charging" mode is actually a runtime extension mode, which is used with external battery packs in order to reduce resistance losses in the batteries. (That is particularly a problem with alkaline batteries that have a high internal resistance.) I don't think overcurrent should be a problem since a properly designed power supply should protect itself from short circuits.

But isn't it really just a matter of reading the device ID resistor and interpreting its value? It looks like the code for that already exists based on what I've seen in the debug menu unless I got it confused with something else.

I guess it's Apple's fault for overcomplicating it. It should be designed so just apply voltage and it gets power. If the source cannot supply enough current, have it do the limiting. (I guess it's a good thing they did not do it with the 12v input!)

[torne]

What about make it an option in the menu for now? Have it default to the current value, but make it an option for users to manually enable it without going through the trouble of compiling firmware. Add in the autodetect feature later.

1) I tend to believe we should try and keep users' hardware safe where possible, unless it's made very clear they are doing something dangerous.
2) It's really not *that* difficult to do it properly.
3) Implementing the option and then subsequently changing what it means will confuse users...

I think the current "charging" mode is actually a runtime extension mode, which is used with external battery packs in order to reduce resistance losses in the batteries. (That is particularly a problem with alkaline batteries that have a high internal resistance.) I don't think overcurrent should be a problem since a properly designed power supply should protect itself from short circuits.

No, you are wrong. The iPod has a standard USB charge controller chip which has a control pin to select whether it limits current to 100mA or 500mA. The USB specification requires that devices draw a maximum of 100mA on connection; they can then present a descriptor which requests more power, and the host will tell them whether or not they are allowed. All USB devices are supposed to work this way (though many badly made ones do not).

The USB charging specification which allows support for AC adapters which provide power over USB without themselves being host controllers was only written fairly recently and is not widely supported by devices or chargers.

The most common failure mode of USB devices which do not correctly follow the procedure is that if you connect them to a bus powered hub, everything on the hub stops working. Hubs very rarely have *individual* overcurrent protection on each port, just a limit on the input current, so when you plug a badly behaved device in, everything on the hub will be disconnected as the hub shuts itself off. Many cheap USB devices/ports *don't* properly implement overcurrent protection, either; there have been documented cases (especially on laptops) of ports being damaged by connecting dumb devices which just draw arbitrary amounts of power from +5V.

But isn't it really just a matter of reading the device ID resistor and interpreting its value? It looks like the code for that already exists based on what I've seen in the debug menu unless I got it confused with something else.

No, it's not. The major issue here is nothing do with Apple hardware or with AC adapters, it's the behaviour of the USB stack itself on connection to an actual host. Detecting AC adapters is secondary (mostly because they generally *can't* be detected, because nobody followed the USB charging spec until recently). We need to follow the procedure in the USB specification for requesting additional power from a host.

As for detecting actual chargers, as far as I know Apple's AC chargers do not connect to the accessory detect pin, they are detected because they pull up/down the USB data pins to particular levels which is read via ADC. Later iPods might *also* detect the data pins being shorted together, which is the standard USB charger detection method. The details of this are not perfectly understood across all models of iPod (they behave differently).

We do not have access to the accessory specification, because you have to pay Apple for it, so accessories which might provide power are very difficult to support: we simply cannot authoritatively determine what the accessory detect values mean for whether it's safe to charge, because we don't know what the spec says.

I guess it's Apple's fault for overcomplicating it. It should be designed so just apply voltage and it gets power. If the source cannot supply enough current, have it do the limiting. (I guess it's a good thing they did not do it with the 12v input!)

None of this is specific to Apple hardware; *all USB devices* are required to behave this way. The fact that some don't is a bug in those devices. I intend to ensure that on devices where we have any control over this, we obey the specification as best we can by default, and only overrride the logic when explicitly told to by the user. I am not just fixing this for iPods


Edit:

additional 1) Actually, making it an option and adding autodetection later basically *is* what I'm intending.. just not in the way you think. I am going to make the USB stack behave correctly when attached to a host, and when we fail to detect a host, it will just go by the value of the setting (which is being changed from off/on to off/on/force).

additional 2) This issue is why release builds reboot to the OF on usb connection. If you want charging to work properly then either use the release build, or apply the patch from FS#8802 yourself and accept the risks...

[NiHaoMike]

As a temporary solution, put it in the debug menu as an entry to temporarily enable charging. I think it is annoying to those who want to be able to use USB for charging. Then it would be unlikely for a novice to accidentally enable it (since it is in the debug menu) and it cannot be left on accidentally since it resets on reboot. But someone who understands what that does can use it without having to compile firmware. (I doubt the average user knows how to compile firmware.)

[gevaerts]

As a temporary solution, put it in the debug menu as an entry to temporarily enable charging. I think it is annoying to those who want to be able to use USB for charging. Then it would be unlikely for a novice to accidentally enable it (since it is in the debug menu) and it cannot be left on accidentally since it resets on reboot. But someone who understands what that does can use it without having to compile firmware. (I doubt the average user knows how to compile firmware.)

That's not what the debug menu is for

[torne]

As a temporary solution, put it in the debug menu as an entry to temporarily enable charging. I think it is annoying to those who want to be able to use USB for charging. Then it would be unlikely for a novice to accidentally enable it (since it is in the debug menu) and it cannot be left on accidentally since it resets on reboot. But someone who understands what that does can use it without having to compile firmware. (I doubt the average user knows how to compile firmware.)

As a temporary solution, the releases boot to the OF on USB connection, which charges fine. The average user doesn't need to compile a patched build, because they are using the release.

[NiHaoMike]

As a temporary solution, the releases boot to the OF on USB connection, which charges fine. The average user doesn't need to compile a patched build, because they are using the release.

Rockbox can already tell the difference between USB and a power supply, since it only reboots into disk mode if it is a USB port. So why doesn't it enable charging if it detects a power supply?

[gevaerts]

Rockbox can already tell the difference between USB and a power supply.

It can't. It can detect the difference between a port with an active host and a port without. The lack of an active host does not imply a charger.

[NiHaoMike]

It can't. It can detect the difference between a port with an active host and a port without. The lack of an active host does not imply a charger.

How does it detect that? From what I know, the iPod will not reboot into disk mode if the data lines are left floating.

I think that problem would mean that accessory devices that supply 5v power (and do not use USB mass storage mode) would be limited in functionality. Could be a pretty big problem for some users.

[torne]

It detects that because active hosts enumerate the iPod and set up a USB connection. It's not detected by voltages.

[NiHaoMike]

It detects that because active hosts enumerate the iPod and set up a USB connection. It's not detected by voltages.

Thanks. I was under the impression it sensed impedances or something.

Is it possible to sense impedance to ground? USB is terminated on the host side with a pair of 15k resistors to ground. So if it's possible to tell the difference between 15k and open circuit, it's possible to tell the difference between USB and a power supply.

[torne]

That doesn't tell you the right thing either. You are assuming that anything which doesn't connect the data lines is a power supply. This is not acceptable as a default.

I'm pretty sure it will work fine for your purposes once the charging rework is done.

[NiHaoMike]

That doesn't tell you the right thing either. You are assuming that anything which doesn't connect the data lines is a power supply. This is not acceptable as a default.

I'm pretty sure it will work fine for your purposes once the charging rework is done.

What else would connect 5v power but leave the data lines floating? That device obviously isn't going to communicate, so the only logical reason for it to supply 5v is for power. (If you're thinking of the case where a wire is broken, I wouldn't bother since all bets are off if the cable is bad. A cable can also short 5v to ground, and there's nothing that can be done on the device side to handle that.)