FS#8363 - Charger configuration for Sansa e200/c200
Attached to Project:
Rockbox
Opened by Bertrik Sikken (bertrik) - Sunday, 23 December 2007, 14:43 GMT
Last edited by Michael Sevakis (MikeS) - Sunday, 11 January 2009, 10:20 GMT
Opened by Bertrik Sikken (bertrik) - Sunday, 23 December 2007, 14:43 GMT
Last edited by Michael Sevakis (MikeS) - Sunday, 11 January 2009, 10:20 GMT
|
DetailsThis is a proof-of-concept patch that demonstrates fast charging for the sansa e200 and c200. It has only been tested on a sansa e200.
The main thing that this patch does, is to configure the built-in hardware charge controller with sensible defaults for the max. charging current and max. charging voltage (previously it was not configured at all). It causes the battery to be charged with a current of max. 300 mA and voltage of max. 4.00V (in unconfigured state, these values are 50 mA and 3.90V). The charge current of 300 mA was chosen a bit arbitrarily, corresponding to a charge rate of 0.40C for the sansa e200 (750 mAh battery) and 0.57C for the sansa c200 (530 mAh battery). The max charge voltage was chosen by looking at the battery voltage of my e200 just after a full charge by the original firmware, in my case this was just below 4.00V. Secondly, this patch changes the ADC channel for reading the battery voltage. Currently, ADC channel "ADC_BVDD" is used, however reading from this channel gives way too high voltages while charging (often 0.5V too high). ADC channel "ADC_RTCSUP" seems to give a much more reliable reading. The measured value from this channel also coincides nearly perfectly which the configured max. charge voltage during the end of the charge, as shown in the attached image. Finally, this patch adds a line in the "View I/O ports" debug menu to monitor the charger configuration and status. This is non-critical but convenient. Please use this patch on your own risk. Increasing the charge current and/or the charge voltage may be harmful to your battery (for example reduced number of charge cycles). For technical info on safely charging lithium battery, see for example: http://www.powerstream.com/li.htm http://www.batteryuniversity.com/partone-12.htm |
battery2.jpg
charge_e200.diff
This task depends upon
Closed by Michael Sevakis (MikeS)
Sunday, 11 January 2009, 10:20 GMT
Reason for closing: Accepted
Additional comments about closing: There's really nothing more that could possibly be done with it at the moment. Works to my satisfaction.
Sunday, 11 January 2009, 10:20 GMT
Reason for closing: Accepted
Additional comments about closing: There's really nothing more that could possibly be done with it at the moment. Works to my satisfaction.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.)
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
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?
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.
* 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
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).
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>
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).
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.
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.
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 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.
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.
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".
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.
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.
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 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.
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
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.
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.
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.
I don't worry so much about the relaxation time, because the voltage vs. charge and discharge curves can be calibrated individually.
* 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.
* 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.
* 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).
BTW, typical charge times seem to be about 2 hours for c200 (measured 1h54) and about 3 hours for e200 (measured 3h09).
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.
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.
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).
For what it's worth, I was also able to reproduce the panic mentioned by mc2739.
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.
/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
Thanks - it compiles cleanly now.
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?
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!
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.
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)
My 2 e200v1s and my c200v1 show similar behavior.
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.
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.
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).