This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9312 - Charging Code for Gigabeat S
Attached to Project:
Rockbox
Opened by Michael Sevakis (MikeS) - Saturday, 23 August 2008, 15:39 GMT+2
Last edited by Michael Sevakis (MikeS) - Sunday, 21 December 2008, 19:13 GMT+2
Opened by Michael Sevakis (MikeS) - Saturday, 23 August 2008, 15:39 GMT+2
Last edited by Michael Sevakis (MikeS) - Sunday, 21 December 2008, 19:13 GMT+2
|
DetailsEnables charging for Gigabeat S.
Can charge through USB. When connected to USB only, the unit seems to have trouble actually doing that since the disk always spinning when connected. At least it seems that way at the moment. The AC adapter will supply enough current to charge regardless. 
gigs-charging-code.diff
(51 KiB)
apps/debug_menu.c | 22 firmware/export/powermgmt.h | 42 firmware/export/config.h | 2 firmware/export/mc13783.h | 16 firmware/export/usb.h | 3 firmware/export/config-gigabeat-s.h | 7 firmware/export/imx31l.h | 24 firmware/target/arm/imx31/gigabeat-s/mc13783-target.h | 6 firmware/target/arm/imx31/gigabeat-s/power-imx31.h | 14 firmware/target/arm/imx31/gigabeat-s/powermgmt-target.h | 98 ++ firmware/target/arm/imx31/gigabeat-s/system-target.h | 4 firmware/target/arm/imx31/gigabeat-s/adc-target.h | 7 firmware/target/arm/imx31/gigabeat-s/system-imx31.c | 36 firmware/target/arm/imx31/gigabeat-s/mc13783-imx31.c | 21 firmware/target/arm/imx31/gigabeat-s/mc13783-gigabeat-s.c | 23 firmware/target/arm/imx31/gigabeat-s/powermgmt-imx31.c | 606 +++++++++++++- firmware/target/arm/imx31/gigabeat-s/adc-imx31.c | 29 firmware/target/arm/imx31/gigabeat-s/usb-imx31.c | 5 firmware/target/arm/imx31/gigabeat-s/power-imx31.c | 46 - firmware/powermgmt.c | 102 +- 20 files changed, 1023 insertions(+), 90 deletions(-) |
This task depends upon
Closed by Michael Sevakis (MikeS)
Sunday, 21 December 2008, 19:13 GMT+2
Reason for closing: Accepted
Additional comments about closing: Ladies and gentlemen, we have charging! The readings look good. Thanks to all who tested.
Sunday, 21 December 2008, 19:13 GMT+2
Reason for closing: Accepted
Additional comments about closing: Ladies and gentlemen, we have charging! The readings look good. Thanks to all who tested.
After adding some additional debug data, I traced the point at which the error state is set to stat_battery_reading, which returns failure unconditionally if the CHGDETS is not set. Modifying the test to fixes or works around the error state, but I am not sure if this is correct. I've attached a patch for this work-around, to be applied over the existing charging patch. I'd especially like to be sure this is not a hardware problem, so if somebody else with an S could verify that the charging patch exhibits the same behavior, that would be a big help.
I can get an error from the stat but it's only if I do things rapidly, not every time since the stat is only done during transitions. It's easier to make happen by unplugging USB with no charger connected (so it is trying to charge from USB)
If this is a real error, maybe instead of some work-around or other to hide it, it would be more appropriate to have rockbox still report the battery % normally while CHARGE_STATE_ERROR is set. This seems sensible to me, if this state really only indicates an error with the charger or charging code, and not with the battery itself. Or I can keep hunting for whatever race condition leads to charging_algorithm_small_step being called with charger_input_state not agreeing with CHGDETS.
I think I will just have it distinguish an ADC error from a "no charger" error which really isn't an error but it should quit trying to charge if that happens. The "race" condition will always be there and must be ok since the thread's info is always slightly behind physical events happening to the player.
I was also reworking that function last night in a different manner so that the target can massage the state to something more general.
Conversion of voltage to % when charging will definitely be a different curve if it is to be accurate because of the rise from internal cell resistance and other effects.
Existing code is was written for software-controlled NiCd and NiMh charging, 100% hardware-controlled charging with software monitoring or no charging at all.
As far as can tell this works really good, i've been using these patches for over a month now.
Also,
This patch needs a resync to work with current revision (19383).
This has a few fancy readouts in the battery debug menu as well. I'll probably keep those even though a couple aren't used for charging. :)
For USB-only charging, after chaging is reported to have stopped, plug the A/C adapter, flip the battery switch off, shut the player down and reboot. The fast you do this, the better. Observe voltage reported by the bootloader (hold a key while booting to pause the screen). Battery must be less than or equal to 4.0V to trigger USB charging.
For AC charging (you should be able to do this immediately after USB charging), simply wait a few minutes until the battery voltage settles. It will flatten-out in the voltage history graph. Battery must be less than or equal to 4.1V to trigger ac charging.
Give readings for each and what capacity battery was charged. It should always settle to under 4.2V. Mine settles around 4.176V for AC and 4.09V for USB-only with the 700mAh OEM battery.
Edit: 4.174V after A/C charging, with same 1000 mAh battery