Anyone facing the battery charging problem? Mine are totally not charging.
Suspect it might BMS problem or battery not fully activate or awaken.
My suggestion are can PI-TOP release the software bin or batch file to activate the battery.
Just my 2 cent opinion.
We need this fixed.
I have been able to provide optimized protection agains the failure of the battery pack also for users of the newest standard Raspbian.
See the separate post "Using standard Raspbian Jessie on pi-top"
You can now achieve the same level of protection with standard Raspbian as with pi-topOS and my battery-status-display. I hope this helps to improve your experience with your pi-top and helps to avoid problems with the battery.
If you are interested in the technical details, I have also attached the following (all measured using an Arduino Mega 2560 with my own software)
Everything is measured while my gtk_battery widget runs
Analog.jpg shows the voltage on the i2c bus, measured at the connector of the hub-controller:
High is 3.3V
Low if driven down by the Raspberry Pi is 0.05V
Digital.jpg shows the logic levels during one i2cget
sniffer.txt shows the analysis by my sniffer program (I have manually added the interpretation of the i2c bus activity in square brackets for easier reading).
I think most of us are waiting on the promise that a new replacement base is being shipped. I saw your message from the pi-top support team regarding a software fault and patch that is forthcoming. If true, It's interesting that this tidbit wasn't posted here for all to read.
Further, I suspect [given the nature of LiPo batteries] most of us with charging problems and batteries that are depleted far below threshold; now have permanently damaged cells. As a result, those in this boat [or pi-top sinking ship] should receive a new base as well as instruction to upgrade and patch the HUB PCB firmware.
According to Pi-Top, if you let your battery fully deplete (i.e. by leaving it running without turning it off) then there is a "known software bug that has occurred infrequently when the battery is fully discharged" [Josh, 31/12/2015] that stops the pi-top charging its battery but still allows the pi-top to operate from its mains adapter.
Pi-Top appear to have realised this around the end of December when they started working on a fix and expected the patch to be released in January.
Mid February I queried the status of the patch and was told "Our engineers are currently doing final testing on the battery patch and we will be releasing the patch on the forum as soon as it is ready. " [Chantal 10/2/2016]
Then in March:
"We are currently in the final stages of the battery firmware batch that will allow for the battery to be fully discharged and recharged; and, this particular patch will be available soon." [Alan, 4/3/2016]
We are now into April and the problem remains unresolved.
Whilst we continue to wait, everyone with a Pi-Top should probably take care not to let their battery run down to avoid hitting the bug because for all we have been told, it may not be an "infrequent software defect" but rather an infrequent occurrence of people letting their batteries fully deplete so that perhaps, if you let your battery fully deplete then you will encounter the problem?
I know Pi-Top is a small team and is doing exciting things but they I do think they need to put more focus on getting the patch out or issuing replacement hubs to sort this problem out for the loyal customers that enabled them to start their journey.
Thanks, Alexandra, for this very valuable information.
I have confirmed that the new link works. I have also updated the detailed step-by-step procedure to diagnose battery problems, which can be found at
As I said before, I believe that one component of the battery saga is the reliability of the i2c bus. Yesterday, while trying to investigate the i2c failure rate in more detail, I stumbled over a very strange finding:
The i2c failure rate increases if he Raspberry Pi becomes more busy. I thought of course first that this might be a bug in my battery program, but I found that both a shell script using i2cget or a small c program using wiringPi show an increasing failure rate as soon as the Raspberry Pi becomes busy running any program which puts a heavy load on it. Sometimes starting any program is sufficient to cause failures.
I have included both the shell script and the source of the c program. I have no experience with python, but I am quite convinced that it would also show the problem.
Is this a kernel bug, a hardware problem on the pi 3 or a current loop problem of the pi-top? I have no clue at the moment and would be interested in your ideas.
Dependencies... any compiler library updates between code outputs will result in different checksums for the same filename.
Enclosed in .zip format a first shot at creating a .html manual about the bq40z60. All comments welcome. In parallel work is near finished on a bq40z60 Status Tool.The unreliable i2c communication is a major headache however.
Happy to report that the firmware update solved by battery issue.
The update was successful on the 21st try (i did it by hand, to see what was going on)
So far the battery is detected and is charging happily.
I've installed gtk_battery 1.1 and the only strange thing that I see is that sometimes the estimated time remaining/time to get full charge jumps to not so sane values (upon reboot i've seen 1096 hours of time remaining while on battery power! :) )
these are the relevant lines in the battery log:
05/17/16 09:01:45 - charging
05/17/16 09:01:50 - charging 44%
05/17/16 09:02:25 - charging
05/17/16 09:02:30 - charging 44%
05/17/16 09:03:05 - charging 45%
05/17/16 09:04:30 - charging 46%
05/17/16 09:05:51 - charging 47%
05/17/16 09:07:16 - charging 48%
05/17/16 09:15:31 - discharging 47%
05/17/16 09:27:29 - gtk_battery version 1.1
05/17/16 09:27:30 - charging 51%
at 9:27 i did a reboot manually.
the battery percentage never jumps values, it's just the approximate hours to full charge/to discharge.
The problem is the so called "i2c clock stretching bug". I have confirmed this by observing the i2c bus on the pi-top during communication with an appropriate device. The problem has been discussed in detail on the raspberry pi forum.
What happens is the following: The Raspberry Pi sends a request for data to the bq40z60 chip of the intelligent battery pack. Quite often the battery pack chip is not able to respond right away. In this case it pulls the i2c clock line low, which is normally controlled by the Raspberry Pi, until it is ready to provide data. This is part of the definition of the i2c protocol (called clock stretching), but unfortunately the Raspberry Pi hardware does not always handle this situation properly. Depending on the exact length of the clock stretching time as compared to the length of a single clock pulse the Raspberry Pi gets out of synch and misinterprets the bits coming from the bq40z60. A further complication is that the i2c clock speed is not constant on the Raspberry Pi. It switches very often and depends on what clock rate the individual core of the processor handling a specific i2c transfer currently runs, how busy the cpu is, what the current temperature of the cpu is, and on various configuration parameters of the OS (overclocking).
As long as one just reads data from the bq40z60, for which it has been developed, such as battery capacity, current and cell voltages, this is not a serious problem. In this situation the bq40z60 is in its protected mode and even if a i2c failure happens, the firmware is protected and cannot be overwritten.
But the bq40z60 can also be put into a mode intended for development on the bench, in which much more data can be read from the device. But in this stage it is also vulnerable because any failing i2c transfer can actually result in overwriting crucial parts of the firmware. It is also wrong to think that as long as one only reads from the device nothing can go wrong, because many i2c read commands actually do write addresses to registers in the slave device. Furthermore, the difference between a read and a write command is just one bit. If master and slave get out of synch this means that read commands can easily be misinterpreted for write commands.
As a consequence I am personally advising strictly against using any software which takes the bq40z60 out of its protected mode, or attempts to read large amounts of data from the bq40z60, even if that software claims to be read only. The risk is just too high that a properly working battery pack is destroyed, possibly even with a fire hazard.
The firmware upgrade of pi-top also takes the bq40z60 out of its protected mode, but I hope that it has been carefully engineered by pi-top, and does not do more that necessary. It should only be used as the last resort if the battery is not charging anymore and everything else fails.
Hope everyone is doing well. :)
So, the long awaited battery-firmware can be patched by running the following command lines below:
To make executable:
chmod +x pt-battery-fw-update_v2`
sudo ./pt-battery-fw-update_v2 -d
Please run sudo ./pt-battery-fw-update_v2 -d 5 - 10 times to ensure the update has been run successfully. :)
If you have any more questions please get in touch with us at email@example.com, and we will be more than happy to help you out! :)
All the best,
I have been doing very detailed investigations and would like to share with you the results. Unfortunately this forum does not seem to accept longer contributions. Please read therefore the attached text file.
I disassembled and reassembled the hub twice to check for damage to the hub/battery connector, and it looks like new. I NEVER get any charging the "battery" program reports (State: Charging Remaining Time: Error) every time. I submitted a ticket on this, and so far pi-top refuses to answer me. I think they have an expensive problem with the battery and they are trying to AVOID TAKING RESPONSIBILITY for their mistakes in manufacturing or quality control. This smells very bad indeed, and if they don't act RESPONSIBLY at this juncture it will certainly spell the END OF THE PI-TOP, as user complaints and word of mouth BAD WILL will swamp all of the good they tried to do!
Same here. Opened ticket with support@pi-top, but no response. When I run the battery command, I get response "error"