Rockbox

Charging algorithms for lithium ion cells vary with the chemistry and design of the cell and without having the specs for the exact cell it would be wise to err on the side of being conservative. 4.0 volts is likely a good compromise choice. If one can accurately measure charging current and temperature, then one could charge faster at a higher voltage, say 4.2 volts and terminate charging when current drops below 0.2 C.

As for the charging current, most manufacturers recommend you stay below 0.5 C although there are some newer cells that can take super high charge rates - as much as 20 C. 0.4 C could be a reasonable choice for the e200 but charging the smaller c200 battery at the same current, ie 0.57 C has a fair risk of shortening the batteries useful lifespan. Another thing to consider is that at low temps cells will be damaged by high charge rates. Very deeply discharged cells are also damaged by high rates. And finally as cells age and degrade their capacity declines and so does their ability to accept current. If you can't accurately measure temp, voltage and current while charging it is better to stay conservative. Without knowing more I would not go higher than a 0.25 C rate as a default and even that would not be 100% risk free under all circumstances.

Charged improperly liion cells can heat up, catch fire or even explode. From 1st hand experience, the fire from burning liion cells is hot enough to cut right through an aluminum bike frame. I wouldn't want to be responsible for someone burning their house down. Someone who left a discharged player sitting for a couple years and then plugged it in to recharge could be at grave risk of this with a blind 0.57 C charging rate.

I understand from your message that we basically know too little about the specific batteries used in the music players. Do you think it is possible/doable at all to safely charge the battery from the rockbox firmware? (there is currently a work-around using the original firmware to charge the battery).

The charge controller in the PP5022 models does have some safety measures already built in:
* apparently there's temperature supervision using a 100k NTC that generates an interrupt on unsafe values (both high and low it seems).
Once the battery is connected to a charger I can also read out some kind of voltage derived from the NTC, if I heat my sansa a bit (e.g. blow hot air from my
PC case over it), the number goes down, indicating that the sensor has indeed some negative coefficient.
* batteries with very low voltages (<3V) are charged with 50 mA max.
* built-in end-of-charge detection (current dropped down to 5-15% of set current), although I've never seen the interrupt bit for this triggered.

It is surely possible to do it safely, but in the absence of sufficient knowledge there is risk. Screwing up typical programming tasks isn't likely to result in injury or death. But in the case of a lithium ion battery charging algorithm a screw up can result in fire. And if the victim started charging before going to bed... Just because it works fine in limited testing doesn't mean one is safely covering all of the extreme edge conditions. But knowing that the charge controllers has built in safety measures regarding temperature and voltage is hugely reassuring. Although if they function by raising interrupts to the software, it is essential that whenever a charging current is enabled the software is able to respond to those interrupts and terminate charging.

The low voltage max charging rate is important protection. Most cell chemistries have extremely high internal resistance at very low charge levels. If you try to push too much current through them they will get hot. The internal resistance drops with temperature increase but this effect doesn't kick in fast enough with deeply discharged cells to guarantee safety except at very low charge rates. Many devices have a low voltage cutoff and if the voltage drops any lower they will not attempt charging at all - although extremely slow trickle charging can sometimes effect partial recovery.

The temperature cutoffs are also critical. This gives protection against cases where folks have left their player in a very hot or cold place (like their car) and then bring it in and immediately attempt recharging. Also as the batteries age their internal resistance goes up - quite dramatically near the end of their useful life. Eventually this renders them useless as the voltage drop while sustaining operating current levels becomes too big. But before they've become useless this high internal resistance will cause more heating, especially when the batteries are deeply discharged (which happens more and more frequently as their capacity becomes inadequate).

Without those protections you have risk of fire that escalates dramatically with increasing charge currents. Even 0.25 C is really pushing ones luck as there might be combinations of age and environmental circumstances that could lead to catastrophe. Again this depends somewhat on the exact cell chemistry as some are more stable and safer than others. But if you don't know what you've got you ought to assume the worst for safety's sake.

But with those protections in place, a 0.5C charging rate ought to be safe. I'd do some testing to be sure that they are functioning and if there is doubt stick with a more conservative charging rate. And a lower charging rate is easier on the cells and will give longer life. I'd prefer a system where a low charging rate (for typical overnight recharging) say at 0.2 C was the default and each time one plugged in the charger they had to manually select a fast charge to get 0.5C.

The voltage drop with heating may not be an artifact of the electronics. More likely I'd expect it is the internal resistance of the battery dropping with raised temperature. If it was charging at a fixed current rate this would cause a drop in voltage. I see this phenomenon all the time with my old bicycle batteries that I often recharge at cold temps. If I raise the charging current limit the voltage drops. Very counter intuitive and therefore a bit alarming - so I use very low current limits with these cells when cold.

You probably aren't triggering the end of charge limiting because the voltage is too low. The end of charge detection only kicks in if you select a higher charging voltage, say 4.1 or perhaps 4.2 volts. That was the point of suggesting 4.0 volts for charging. Fairly safe to leave the cells left indefinitely hooked up to a voltage source at this level. The current will slowly trickle off to next to nothing without the batteries ever exceeding 80 to 90% of a full charge. Which is a good thing for extended life. Left on indefinitely at 4.1 volts you might reach or slightly exceed full charge and at 4.2 volts you will almost surely slowly overcharge and cook the cells - especially older cells.

In your first comment you mentioned getting different voltage readings while charging. The high BVDD voltage is the source voltage which must be higher than the battery internal voltage for charging current to flow. If the battery is deeply discharged and the current limit is set high then getting a big difference is possible, although 0.5 volts is quite large, especially with a max voltage of 4.0. For good life on most cells you really don't want to drop them much below 3.5 volts unloaded. The amount of capacity remaining between 3.5 volts and 3.0 volts is probably less than 15%.

It is a bit difficult to quickly get an accurate reading of the battery internal voltage while charging as after removing source voltage one has to wait for the battery internal voltage to settle. It will fall over time towards the true internal voltage on a curve similar to a capacitor discharging through a resistance. One can accelerate this settling by applying a load to the battery. Do you have any docs on the charge controller?

I don't see why we couldn't just check that the battery voltage/temperature is in some reasonable range before applying full current/voltage. If its outside that range, then we could just trickle charge it or even do nothing and force the user to charge in the OF (which presumably can handle all cases safely).

Yes, I have a datasheet of the device that manages charging (among other things) and which is integrated the PP5024 main controller. I got it from one of the main developers and promised not to spread it further. If you explain your intentions to them I think you can probably get a copy too. It would make a lot of things much clearer.

The voltage drop I was talking about is not a drop in the charging voltage, but a drop in the voltage measured through the BATTEMP ADC channel.

saratoga, the temperature limits are already built into the charger hardware, we have hardly any control over them (other than disabling the NTC completely) and we don't even know their exactly value, nor how to calculate the battery temperature from the ADC reading. The low voltage limit is also built into the hardware.

I still think the BVDD voltage is the wrong one to look at. As I'm charging now with 200mA/4.00V, it reads 4.605V, while the RTCSUP voltage reads 3.988V, very close to the configured charge voltage.

But you do have access to the raw voltage reading coming out of the probe (I'm guessing this is the third battery terminal)? If so can you interrupt charging if it exceeds some threshold or do you not know how to do that? Seems like we could experimentally determine a safe maximum temperature even if we don't know the exact calibration curve for that thermocouple/diode.

bertrik: Are you still interested in working on this?

I looked at the battery temperature probe using a DMM, and it seems like we could quite easily measure the voltage corresponding to a maximum safe temperature and simply disable charging if its exceeded.

Yes, I am still interested in e200 charging.
I don't see the point at all in doing temperature probe measurements. The PP5024 already has safety circuits for temperature built-in, so I see no reason to worry about that.

I am however interested in a comparison of the actual externally measured battery voltage during charging and the numbers that we see from the various ADC channels. This would confirm (or not) whether channel ADC_RTCSUP is actually a better indicator for charging battery voltage than channel ADC_BVDD.

Measuring the voltage externally would be somewhat difficult because you can fit the battery in the socket, or a probe, but not both. I could hold a probe to the battery and then connect it to the sansa +DMM at the same time, but that would only get a couple seconds worth of reading i think before i'd slip and the probe would come off. Is that going to be enough or do you need steady state measurements while charging?

I really appreciate you guys working on this... (This patch does apply to the e and c series, correct?)

saratoga, yes I think that a couple of seconds would be enough. I think voltage measured by the sansa itself is quite stable. Perhaps this is simple enough to have a try myself :)

strife89, I only have a sansa e260 to test this on. The e200 series has a higher capacity battery than the c200 series, so for the c200 series the charge current as currently defined in the patch may be a bit too high. For now, I think charging the battery with the OF is still a perfectly acceptable work-around.

Synchronised against svn 16657. Also increased the max. voltage a bit to 4.1V (OF does seem to charge up to 4.2V) and decreased the max. charging current a bit to 250 mA.

I have tested this patch because booting into OF just for charging is too much of a hassle. With this patch charging works fine for me.

While playing around with charging with the USE_ROCKBOX_USB define set, I've noticed the following though:

Prior to revision 16611 (or just 16611 reverted), and without this patch, my e280 fully charges if starting it with the cable plugged in. An incomplete USB screen should appear as lots of things are not yet loaded at that point. Now 16611 fixed the USB screen but broke charging for me, the reason I tested this patch.
It appears that the original bootloader already configures the charger but Rockbox later unconfigures it during the later parts of the startup sequence.

Hmmm, interesting, 16611 is a USB fix and should not have much influence on charging I think.
If the OF indeed pre-configures the charger, could you look up the contents of AS3514 register 0x22?
Another possibility is that the AS3514 charger circuit is mis-configured because of a bug in the sansa reboot procedure that was recently fixed. This happened when the USB plug was inserted causing the charger voltage limit to be set to its maximum value (possibly dangerous for your battery).

Please keep in mind that this patch is still a very simple proof-of-concept patch. Although it won't damage your USB port, it draws more charging current from the USB port than officially allowed (max. 100 mA if the USB device is not 'configured' yet by the host OS). For proper charging there should be some kind of communication between the USB code and the charger code to tell the charger when it is OK to draw more current.

I've added this before any other initialization routine in bootloader/main-pp.c:
int charger = i2c_readbyte(0x46, 0x22);

And later printing that value:
printf("Charger configuration: %d", charger);

The value it prints is 62 (0x3E). Which would mean a voltage of 4250mV and a max current of 200mA.

On the IO ports debug screen this value is shown as 0x3E as well.

If not plugged in, it's zero both at the RB bootloader as well as in the debug screen.

I think I misinterpreted what happened before, r16611 does not seem to affect charging at all. Only important thing was to start it while plugged in.

Thanks for the info. Wow, I find the high voltage of 4250 mV a bit surprising but the current seems a reasonable value.

betrik: Think we should commit this then? Though personally I'd prefer a bit lower max voltage for the sake of improved battery lifetime.

saratoga, no please don't commit this yet. The point of the patch was to show that it works in principle. For example, I think a full patch should also include some kind of indication from USB to the charger when (or when not) it is allowed to draw >100 mA charging current.

Hi,

At the risk of sending you off on a wild goose chase, there is another phenomenon that could be relevant.

E200s using the OF are known to be fussy about which USB ports they want to connect to. Front USB ports are generally worse than rear USB ports. I assume (with very little evidence) that the OF asks for more current than some USB ports are willing and able to deliver.

If your code detects a problem is it able to try again making progressively smaller requests?

As far as I can work out the PortalPlayer inside an e200 claims to be compliant with USB 2.0 and OTG, but the e200 as a whole makes no such claim. Perhaps the OF is not as smart as it should be. The box that my e200 came in does have a list of requirements which include, "High-Speed USB 2.0 high-power port required for Hi-Speed transfer". I do not know what "high-power" is defined as. Neither do I know why they can't decide on "High-Speed" or "Hi-Speed". ;-) Perhaps some motherboards/ports aggressively limit current to 100mA even if negotiation has occurred.

Has anyone tried measuring the current drawn by the OF? Measuring it would require cutting wires - so I understand if nobody is keen on doing it.

Peter, my code is very simple and just applies a default charge setting. Currently there is no link between the USB sub-system and charging at all.
I'd like to work on that but the power management part of rockbox is rather complicated in my opinion (about 10% of that is pre-processor code!).

Ideally the USB sub-system should communicate with the charging sub-system to know the max. charging current and advertise this in the USB device descriptor. Then when the USB device gets configured by the host OS (not before that!) the charging sub-system is informed that charging is allowed.

Motherboards that limit current to 100 mA even if negotiation has occurred are not compliant to the USB spec and adding a work-around for this should only be done (IMO) if we're really sure what is going on exactly and only as a last-resort measure. The same goes for USB ports that are "fussy" with the OF in my opinion.

Hi Bertrik,

I'm sorry if I am wasting your time.

I've cut up a USB cable and measured the current. Starting with my Sansa e260 turned off, it has an inrush current that rapidly climes to about 160 mA which it draws for several seconds before dropping to about 70 mA. (After the OF is running.) No wonder there are problems with some USB ports.

Unless your code is in the boot loader it has nothing to do with this problem. Do you know who, if anyone, would be interested in this?

[quote]I've cut up a USB cable and measured the current. Starting with my Sansa e260 turned off, it has an inrush current that rapidly climes to about 160 mA which it draws for several seconds before dropping to about 70 mA.[/quote]

Thats normal because of boost + backlight during powerup. Rockbox does the same thing.

[quote]
No wonder there are problems with some USB ports.
[/quote]

USB provides up to 500ma, so that fine.

Peter, I apologise if my earlier responses were a bit harsh. Your current measurements are very useful. Basically it proves that the OF is not completely compliant as USB devices can only draw 100 mA until they are fully configured by the host, which may indeed explain the "fussy"ness you described.
A very interesting experiment would be to measure the current drawn by the OF when the battery is nearly empty and when it has fully charged. My assumption is that the the fully charged current is the "idle current" of the OF (since battery charging does not take any current anymore). Subtracting this from the nearly empty current should give a very good indication of the current going into the battery. (Assuming that there's no DC-DC converter between USB power and the battery, so USB currents can be directly compared with battery current.)

Bertrik,

I didn't notice anything outrageously harsh. Don't worry about it.

Assuming that the battery is a genuine 750 mAh then a charge life of 20 hours would give a minimal drain of 37.5 mA.

When the battery is half full the surge maxes out my cheap multimeter at 200 mA. I'm not sure what code is running at the time, the OF bootloader, the RB bootloader or the OF.

I think that I should make some more measurements then start a new thread under hardware.

Is there a description of the boot sequence somewhere? This is the nearest that I have found, http://www.rockbox.org/tracker/8642

Synchronised against 17131.

Bertrik,

Would you like me to test this?

I've got 17131, applied your patch and compiled it, but am I supposed to set USE_ROCKBOX_USB somewhere?

I don't think the charger is even aware that USB exists, so enabling the USB stack shouldn't matter. They're actually handled by different chips, although they both happen to be colocated on the PP5024 SOC.

bertrik: Since the OF ignores the USB current limitations, and we know the settings it uses to charge the battery, I don't see any reason to keep this out. The worst we can do now is skirt the rules as in the retail firmware. IMO it should go in, and then when the USB stack is enabled we can use that to request proper current before charging.

What further analysis or testing is needed for this patch to go into the main code?

Updated (experimental!) patch, with the following changes:
* charge current now depends on battery capacity (C/3) so should definitely be safe for c200 now
* enabled charge status bits so the high-temperature and end-of-charge bits can be read too
* implemented charging_state function, which indicates whether charging is currently active
* charger is turned off when the charger indicates end-of-charge

saratoga, I think you're right about concentrating first on making charging work first and integration with USB later.
Peter, there's no need to enable USB if you want to test this. The way I test this, is by entering the I/O ports or battery debug menu, then plugging in the cable. In the I/O ports debug menu, you can see the charger status (xx/yy on e200, where xx is the charger configuration register and yy is the charger status register). ADC_RTCSUP is the battery voltage (units of 5 mV).

I've experimented a bit more and am running into some strange issues.
First, there is an end-of-charge signal in the charger status register, about which the datasheet says to stop charging when it becomes active. When charging with the battery already at a quite high voltage (>4V, e.g. just after the OF charged the battery), the end-of-charge signal never seems to become active. The configured voltage limit does seem to be respected though as I can see a flat graph in the battery menu with a voltage corresponding exactly with the limit.
Second, when charging the battery from a partially discharged state (<4V), the end-of-charge signal does become active at some point, but it at too low voltage (less than configured, measured 4.087V instead of 4.100V). It seems to become active while the voltage is still rising during charging (i.e. during constant current mode, before constant voltage mode). When the charger is turned off at this point (but cable still connected), the battery voltage drops over the course of several minutes to a slightly lower voltage (measured 4.065V ) and stays there. I would have expected it to gradually drop further after the charger is turned off.

Ideally, for a safe charge, I think charging should start when the charging cable is plugged in, and stop when end-of-charge is detected by the hardware. However I'm bit confused about what to do with the end-of-charge signal because of how it seems to work. Perhaps _NOT_ turning the charger off isn't that bad as long as the charging voltage is not too high (I expect the charging current to taper off automatically in constant-voltage mode).

Bertrik,

Have you been able to measure the current during this strange behaviour?

Is it possible that the intended behaviour is to charge until "something happens" (the end-of-charge flag is set, temp too high, voltage too high, whatever) then stop charging until everything is OK (minutes to *weeks* later) then start charging again. GOTO 10 ;-)

Look at Figure 1 of <http://www.batteryuniversity.com/partone-12.htm>

Peter, what do you mean? What part of that page should I look at? My impression so far is that even stage 1 is not completely finished.
I plan to start the charge on plug-in, then keep charging until the end-of-charge signal (or temperature high flag) becomes active, then stop charging. The problem is that the end-of-charge indication seems unreliable.

A possible explanation may be that the charger circuitry itself compensates for the temperature therefore terminates a little on the early side if ambient temperature is already quite high (as was the case in the past few days). Possibly I may also have to add a check before charging that the current battery is already sufficiently lower than the maximum charging voltage (but how much is sufficient? too bad that the hardware doesn't do this by itself).

Bertrik,

What I was referring to was that the higher the current rate for stage 1 the less it is genuinely charged when it appears to be nearly full and the longer stage 2 takes. After briefly charging with the OF and then running RB the % battery charge plummets in a few minutes. After a very rapid charge the battery might appear to be full when it is only 70% full. (Same reference.) This "false full" signal might be what is confusing things.

If we measured the current during charging we would have a better idea of what is going on. If the charging is stopped as soon as the end-of-charge signal appears I would expect the end-of-charge signal to go away sooner or later. (In a few minutes if the battery has had a rapid charge and the Sansa is running, or in a few weeks after a slow charge with the Sansa turned off.) As to why the end-of-charge signal does not appear soon after an OF charge it might be that the OF charges quickly and you are actually giving a long stage 2 charge when you thought that you were in stage 1.

It might be worthwhile stop as soon as anything happens then start from stage 1 again but with a lower current after everything is clear. That is just a wild assed ignorant guess, not an expert opinion.

I currently have r17307-080502. The "CHARGER:" line changes from 00/00 to 00/20 when I press select and connect the cable. I'll have to scratch my head and work out how to use svn again. I did it once, so it can't be too hard.

Hi Bertrik,

You had better tell me exactly what to look for. I've compiled r17423 with your patch. A couple of chunks were rejected, but I worked out how to insert them. I have a butchered cable that connects a USB header to a PC case front USB socket and I have connected my cheap 200 mA multimeter to it. I will have to try and find a USB socket with cable attached so that I can use the high power back USB ports rather than the low power front USB ports.

The "CHARGER:" line shows 48 or 01 before the slash and 20, 40, 80 or briefly C0 after the slash. What do those bits mean? A "1" before the slash means that the charger is disabled, but the battery does not seem to discharge at all. I assume that the Sansa draws all of its power from the cable in this situation?

At the moment, the battery charge seems to stabilise at about 88%, which is not a bad thing for a long battery life.

It is possible that there is a hardware bug causing the odd behaviour or end-of-charge. Maybe it only detects a threshold crossing rather than threshold exceeded.

Feel free to email me, p13 at g-node dot com dot au.

New multi-meter! My e200 is drawing more than 300 mA (battery at ~80%) with the OF and it is not connecting (using the header that normally goes to a front USB port).

It is possible that I have reversed the data + and - with my cannibalised bits and pieces, but I think that the real problem is that the power line is dropping to 4.65 V. Specifications demand that the device not draw more than 100 mA before negotiation and that the host maintain > 4.75 V. Sandisk appears to be a long way out of spec. :-(

I've bought a USB extension cable and cut it up, so I can measure current more easily.

I've changed my mind about why the e200 is so fussy about USB ports. It draws way more current than it is supposed to without negotiation, but I think that it has a timing problem that is affected by the length and quality of the cable.

Are you measuring the voltage drop across the Sansa with the ammeter connected? If so, that might explain the low voltage. Otherwise, a low USB voltage probably means something is wrong with your PC.

Attached is an updated patch which also fixes a bug in the c200 part.

Peter, it would indeed be very useful to know the current drawn just during the various charging status with this patch (just connected, just before stopping charge, etc). The bits after the slash are influence by the various charge bits, bit 7 is the temperature high alarm, bit 6 is the end-of-charge bit, bit 5 is the charger connected status.

Saratoga,

Yes, I'm using a voltmeter and an ammeter at the same time. There should not be much of a voltage drop across the ammeter. There seem to be a lot of things that are marginal at the same time, so I am not sure what to swear at at any given failure.

I can't really blame the motherboard for not maintaining the specified voltage when the Sansa is drawing an out of spec current.

Bertrik,

I'm using r17614M. There was a rejected chunk in firmware/export/config-c200.h about CHARGING_MONITOR versus CHARGING_MONITORING.

0x20 => charger connected
0x40 => end-of-charge
0x80 => too hot
?
That would mean that my battery starts out too hot at boot, before connecting the cable.

With the battery at about 98%;
the charger line shows "48/80"
plugging the cable in does not cause a re-boot (no button press, viewing I/O screen, or main menu),
it draws 0.07 or 0.08 Amps (the resolution is only 0.01A on the 10A scale),
the charger line changes to "48/20".

Try measuring without the ammeter in place. A 100mV+ drop sounds about right if you're driving the ammeter past its full scale value, since its basically just a resistor, and the assumption that the voltage drop across it is small only applies if the current through it is also small.

Saratoga,

I'm surprised, on the 10 A range the multimeter has a resistance of about 0.5 Ohms, more than enough to cause a 100 mV drop.

Bertrik,

With the battery at ~20% and the I/O screen showing 48/80 plugging the cable into the e260 draws 0.31 A and "CHARGER:" went to 48/20. It rises to and stabilises at that value in about a second, fast enough that any delay can (probably) be blamed on the multimeter. Then when the screen times out the current drops to 0.29 A.

After a few minutes I moved the ring, the screen came on and the current went to 0.32 A. It rapidly fell to 0.30 A, with the screen still lit. Then when the screen timed out current fell to 0.29 A again.

Then I disconnected and booted the OF. for comparison. Current was 0.35 A, which rapidly fell to 0.34 A with screen lit. BTW I was getting kernel messages about "usb-storage: waiting for device to settle before scanning".

Rebooting RB the battery was at ~50% (it was probably not really that high) it drew 0.29 A after the screen went out.

At ~80% battery the screen out current dropped to 0.28 A.

The screen off current fell to 0.27 A at ~83% battery.

I'm unplugging and going to bed. Goodnight.

Overnight the battery relaxed to 68%.

The screen off current was 0.27 A.

The screen off current dropped to 0.25 A at ~83% battery.

0.24 A at ~87%.

0.23 A at ~88%.

0.20 A at ~89%.

0.15 A at ~90%.

0.10 A at ~91%. Then the "CHARGER:" line changed to 01/20 and the screen off current dropped to 0.05 or 0.06 A.

I then booted the OF for comparison. The current was about 0.07 A with the screen on and was not maintaining a connection.

With the OF, the fun starts after things have stabilised at about 90%. After a while (an hour?) and a few reboots the OF starts another charging cycle ( 200+ mA, 4.2 Vbat) which takes the battery to 100%. I re-booted several times during this stage and RB thinks that the end-of-charge bit is set.

Maybe it is waiting for the battery to cool. Maybe they are waiting for the internal chemistry to stabilise. Maybe it's a bug. I'm just making wild guesses here.

It is only during this second cycle that I get stable USB connections (with the OF).

I've changed some hardware.

I seem to have destroyed a couple of USB headers on my motherboard. Quite possibly that was my fault. Also I believe that the Sansa hardware is outside. Anyway, I've bought a PCI to USB card and it gives stable connections even if two USB extension cables are used.

Peter, thanks for your measurements. It looks like the OF uses 300 mA charge current.

I now have both a sansa c200 and an e200 (which both use the AS3514 for charging), so I hope to get a more complete picture. From some experiments with the c200, it looks like the charge current can be roughly estimated from the CHGIN voltage read through the DAC, so we can for example see if the charger is working in constant-current (at the start of the charge) or in constant-voltage mode (near the end of the charge). It looks like this can be done with the e200 too.

I'm trying to collect the conclusions from this thread in the wiki: http://www.rockbox.org/twiki/bin/view/Main/SansaCharging

I lost half a sentence from my last comment. It should have been, "Also I believe that the Sansa hardware is outside *USB 2.0 specifications*".

The peak current I measured was 0.32 A, so 20 mA to run the device and 300 mA into the battery sounds right. Especially if the charger is only configurable in 50 mA steps.

The remaining weirdness is the way that the OF will charge most of the way and then stop for ages before a "topping up" phase. I think that that behaviour is a Sansa bug rather than a feature - but I can't prove it.

A well engineered USB host will not be damaged by plugging a Sansa into it, but it might be worth trying to make a Sansa with RB better behaved than a Sansa with the OF.

If in doubt be cautious.

Would you like me to make any more measurements? That is really all I can contribute.

No more measurements are needed. I built a simple USB current measurement setup (just a 1 ohm resistor in line with VBUS), so I can do any further measurements myself. I can not reproduce the problem anymore where the battery keeps charging forever, perhaps I somehow misunderstood something when doing that experiment (e.g. forgot to enable the interrupt bits that indicate end-of-charge). It's now time to seriously start implementing, I'm thinking of a simple three-state machine (idle, charging, charged) kept alive by the charging_state() call from powermgmt.c.

One thing I'm not so sure about is how to indicate charge progress. It seems the rockbox model is to rely purely on voltage to calculate the charge level and charge progress, but for c200 the charge voltage is not available and for e200 the charge voltage may remain static during the constant-voltage charge phase. I think it would be nice if powermgmt.c would not assume that knowing the battery voltage is enough. Alternatives would be:
1) stop charging for a few seconds once in a while (say every minute) to measure the battery voltage.
2) determine progress by calculating the charge current from the difference (CHG_IN when not charging vs. CHG_IN during charge). For example progress = 100% * (max. charge current - current charge current) / max. charge current.
3) for e200 specifically we can measure RTCSUP to get the battery voltage during charge, but this feels a bit like a hack.

When you write that you are not sure about indicating charge progress do you just want to indicate to the user that charging is or is not happening? I think that that is all that the OF does. Or are you thinking about the more fundamental problem of detection?

If you stop charging to measure the battery voltage you might have to wait a while for the voltage to relax. I'm not sure how long "a while" is, but the worst that is going to happen is that charging will slow down.

Ideally, the rockbox battery indicator should indicate the charge level (0-100%) during charging, not just if it is charging or not. If possible, rockbox should improve on the behaviour of the OF. The problem as I perceive it, is that rockbox can indicate charge progress only by measuring the voltage during charging. IMO this is indeed a fundamental rockbox limitation. For example rockbox could leave it up to <target>-power.c to calculate the charge level by whatever means and not automatically assume that it can read a voltage during charging (from the same ADC channel as during normal use).
I don't worry so much about the relaxation time, because the voltage vs. charge and discharge curves can be calibrated individually.

Attached is a new patch for c200/e200 charging, main features:
* Now contains a simple state machine to start charging on plugin and stop when the charger indicates it is done. Replugging restarts the charger.
* Charge current is simply set to 300 mA as this is the setting that the OF seems to use, regardless of battery capacity. Charge voltage is set to 4.200V.
* On e200 the battery voltage has a realistic value by using the ADC_RTCSUP channel, this does not seem to be possible on c200 (voltage is too high to be realistic)

The earlier idea of stopping the charger every few minutes to take a more realistic measurement cannot work because even with the charger stopped, the battery voltage is still way too high. In the future, we could do something advanced with charge current measurements to estimate charge level or progress, but that would require quite a big change in powermanagement.c, so this patch keeps it simple.

Updated patch:
* charges c200 and e200 with 300 mA max current and 4200 mV max voltage
* charging starts on cable plugin and stops when charger indicates it is done
* fixed problem where charger would not always detect end-of-charge
* cleaned up state machine and added protection against concurrent access.

As of the August 17 patch, would anyone say that it's safe to charge my c250 now? Or are there still some kinks?

I'm pretty confident now that it is safe:
* The charger hardware itself has several safety measures already built-in.
* The maximum current and voltage settings were measured from the OF (possibly voltage is even a little safer than what the OF uses).
* Charging is stopped when the charger indicates charging is done or when it indicates the battery is too hot.
* I've identified and fixed the problem where end-of-charge would not always be detected if the battery voltage was already pretty high.
The only thing left is that there is no interaction yet between the charging part (drawing 300 mA current) and the USB part (requesting max. 500 mA current).

This works very well with my e260. Though, the charger doesn't seem to do the constant voltage phase. As soon as 4.2V is reached, it switches off (screen dump attached). Personally, I don't care about that. It will surely increase the battery life. Just wondering whether it's an issue with my device.

Martin, I see the same. It seems the transition from constant current to constant voltage is a rather soft one. As the voltage approaches the voltage limit, the current is already dropping. The end-of-charge point is determined by the charger hardware as the instant where the charge current has dropped to about 10% of the configured maximum charge current.
BTW, typical charge times seem to be about 2 hours for c200 (measured 1h54) and about 3 hours for e200 (measured 3h09).

Bertrik: "...there is no interaction yet between the charging part (drawing 300 mA current) and the USB part (requesting max. 500 mA current)"

I'm sorry to say that I'm not totally sure what that means, but I'm guessing that when plugged into a USB port for both charging and data, it doesn't charge (I have enabled the USB stack)? Have you used a stand-alone charger device (like this one: http://sector29.com/PRODUCT_PAGES/249/249-M57322-F8M055.html)? I own one, so I'll probably just use it.

You're supposed to ask before drawing the full 500ma from a USB port, and then not do so if the USB host refuses. From what I understand, we currently ask, but ignore the answer and draw power regardless.

Isn't usb_allowed_current() in usb_core.c suitable for that? Maybe just don't switch on the charger until it returns 500 mA. Or calculate the charging current form the returned value. Somehow informing the user about why it's not charging would be good.

Yes, I think usb_allowed_current should eventually be used (changing the charging current is easy), but in case of a dedicated charger, we should not ask USB for permission :) I doubt very much whether the OF uses USB queries to determine charge current, so the current behaviour is not that bad IMO. The patch may change as rockbox USB eventually gets enabled and perhaps also when jhMikes commits his powermanagement changes for the gigabeast, but I think the current incarnation is basically the best we can do now.

I'm certainly satisfied. Charging works quite well on my Sansa c250. Kudos to you all. :)

Great work on this patch Bertrik. It sure is nice to charge my e200 while using it. I have turned up one problem though.

Use the following procedure to duplicate:

power on e200
press select and insert USB cable
press long power

*PANIC*
Stkov (0)

charge_c200_e200_r18308.patch was the only patch added to the test build (tested on r18545, r18569 and also the Rockbox 3.0). All settings were at their defaults.

I think the panic is not related to charging, I've seen it also without charging on shutdown when USB has been plugged earlier.

Unfortunately, the problem where the end of charge is not detected by the hardware when the battery voltage is already quite high is not fixed yet (I thought I nailed it). It doesn't seem to be very harmful because charge current is basically 0 when it happens. The datasheet of some of the other AS35xx chips mention that the end-of-charge interrupt bit should not be enabled when no charger is not connected, so I tried to enable it only after the charger was connected, but no success yet. Possible solutions: 1) investigate further 2) use a higher charge voltage so the conditions for the problem never occur 3) check battery voltage before charging (can be tricky because just plugging in the charger already disturbs the battery reading).

I tested with clean builds before I posted above and I was not able to reproduce the panic. The panic occurred every time with the charger patch applied.

I've just built r19053 with the August 17 2008 verion of this patch. Charging on a c240 seems to be working correctly with USB ports on a laptop and desktop PC.

For what it's worth, I was also able to reproduce the panic mentioned by mc2739.

This patch is now broken since r19315 was committed this removed usb charging option from sansa c200/e200

I'll give some time to this and bring it into the new framework.

I did some checking on a known low-power hub (in fact, an unpowered hub on a keyboard) using retailos and windows XP and it makes no effort to consider configuration by the driver. It says "USB Hub Power Exceeded" and fails to mount any volumes. Retailos still reports charging on the battery indicator however though who knows if its really is; I didn't wait around to find out. As far as I'm aware there's no way to know which sort of input is present. The information from the IRQ_ENRD0 register gives strange output as well (0x08 = USB not plugged, 0x02 = USB plugged) and flips through 0xA and 0xE really quickly when plugging/unplugging.

Here's an update using LiIon charging methods gleaned from the beast work. It includes automatic recharge mode when battery level drops on its own to 4.100V while plugged, Will allow topoff when first plugged and battery is less than 4.160V (to avoid excessive retopping). Handles system shutdown, temperature errors and timeout errors.

Important things:
1) Don't even look at IRQ_ENRD0 _anywhere_ besides the battery code; it can clear status bits (very common for PMIC).
2) Dummy read it after first enabling the interrupt bits after turning the charger on to clear them.
3) ADC_RTCSUP _is_ the correct channel for the battery terminal given what I've observed.

Never mind about the battery voltage. It's within regulation during CV and ENDOFCH is set when the current level reaches 10% of nominal.

EDIT: Forgot to define HAVE_POWEROFF_WHILE_CHARGING. No need for a new revision.

One thing I'm not clear about is if fast charge is enabled automatically after precharge mode on a low battery (< 3.0V) or if we have to monitor that.

So...see how it goes.

I get this when compiling for c200:
/home/user/rockbox/build/apps/debug_menu.o: In function 'view_battery':
debug_menu.c (.text+0x1490): undefined reference to 'ascodec_read'
collect2: ld returned 1 exit status
make: *** [/home/user/rockbox/build/rockbox.elf] Error 1

Mark, this should fix the c200 issue. I got the same when I checked and it compiles now.

Mike,
Thanks - it compiles cleanly now.

I'm not sure this is working for the c200. I drained my battery overnight, then this morning connected the PC USB cable while holding down SELECT. The WPS shows the AC connected power icon, but after approx 4.5 hours I disconnected the USB cable, and the battery charge is shown 9% (40mins).

Battery voltage shows as 3.642V in the Debug menu.

The USB port/cable combination I'm using is the exact same one I use when charging via the OF

Perhaps I've missed something?

I agree I don't think its working either
No charging icon in wps only connection
Battery voltage shows as 3.689V in the Debug menu.
As soon as the charger is plugged in this jumps to 4.745V

Looking at the comments above I think the patch doesn't catch the lower voltage and is in fact seeing the charger voltage no idea how!

This defines thresholds differently depending on target.
e200 can read the battery accurately in all cases, voltage is monitored for topoff and restart.
c200 should simply trigger the charger for one cycle upon plugging. I've been enlightened to the fact there is no way to read the battery accurately when plugged.

robin, given the that you aren't seeing the correct battery info I meant to ask if it is in fact a c200 v1 you are using. I'm not evaluating any v2 stuff here. It's the only reason I can think of that the charging view wouldn't be right.

Mike, charge_c200_e200_r19728.patch seems to charge correctly.

I did notice something similar to Robin .... after a charge cycle, I used the DAP a while. The battery voltage was approx 4.175V and I connected the USB cable. After about 15 secs the voltage jumped to 4.6V. After a few mins it was up to 4.752V. When the USB cable is disconnected, the voltage drops to 4.187V.

I'll drain the battery overnight and monitor the voltages more closely during the charge cycle.

(mine is a v1 c250)

I believe the charging hardware on the c200/e200 is incapable of reporting proper voltage while the charger is connected.
My 2 e200v1s and my c200v1 show similar behavior.

robin seemed to have other troubles since a key part of the patch was reported to be absent in the battery debug screen. So, either it was the wrong c200 type or the patch wasn't applied or was improperly applied.

e200 is perfectly capable of reporting battery voltage accurately (via RTCSUPP) and this is configurable to make the most of info the target is capable of providing. On c200 when plugged the voltage is ignored and the charger is just started and the battery is not monitored for maintaining the charge; it's not the best way to go but it's all that can be done.

Anyway, this update jumps through _all_ hoops that Bertrik figured out about the as3514. I wasn't watching the CHG_status bit before attempting a start but that is fixed. It didn't affect my e200 but perhaps some cases are different. Additionally, it brings the powermgmt thread priority to realtime when the charger is on so it never gets starved when monitoring the hardware. I would like to add some kind of watchog timer use to protect against losing control in case of a lockup where it wouldn't be possible to shut down the charger properly (safety first) but I don't know at this moment how to use a watchdog timer on PP.

While I was discharging after yesterdays test with charge_c200_e200_r19728.patch, I ran a battery benchmark (attached).
c250 with 8GB sdHC card. Backlight permanently on. Volume max with Sennheiser CX300 headphones. One track set to repeat.

I'll try the latest patch tonight, and do another battery benchmark to compare performance.

Mark, looks good in comparison to other c200 benchmarks (given the backlight is fully on). The r19731 patch stops charging based on the same signal so I doubt it will change the outcome. Any difference would just be normal variability. Perhaps try in backlight off mode.

I somehow forgot to start the battery benchmark, but running with backlight off (apart from caption backlight) after charging using r19731 patch it played continuously for somewhere between 14 and 15 hours.

It sounds like c200 is actually working well. e200 is definitely working well for me. I'll clean up and simplify what I can and consider committing this.

One change I'll make is to let the hardware supervise the temperature instead of intervening with software since it stops the charger upon overtemp (55C) and allows the charger to restart if temperature normalizes (50C).