[Letux-kernel] fix for bq24297 and PLS8 issue

H. Nikolaus Schaller hns at goldelico.com
Wed Aug 15 21:53:45 CEST 2018


Hi,

> Am 15.08.2018 um 20:15 schrieb Amber Schenck <ambersck at hotmail.com>:
> 
> Date: Tue, 14 Aug 2018 20:44:50 +0200
> From: "H. Nikolaus Schaller" <hns at goldelico.com>
> To: kernel at pyra-handheld.com
> Cc: Discussions about the Letux Kernel <letux-kernel at openphoenux.org>
> Subject: [Letux-kernel] fix for bq24297 and PLS8 issue
> Message-ID: <4D463D42-4093-483F-BFCE-55B24B222C34 at goldelico.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi,
> I know that there are many silent readers here, so let me
> share an adventurous story, how developer's work can go...
> 
> Three weeks ago I tried to experiment a little more with
> the PLS8 modem of the Pyra and learn about the AT commands.
> You know, I am the hardware guy and have just plugged things
> together by connecting wires (in CAD).
> 
> This worked well for the first experiments. But suddenly the
> modem did no longer respond to any AT command.
> 
> The symptom was that after doing an "rfkill unblock wwan"
> the modem did power up and register as an USB client and
> even created some /dev/ttyACM1 as usual, but immediately
> deregistered from USB and turned off again.
> 
> Therefore, I asked for technical support from the distributor
> of the PLS8. And at the moment he asked for details I tried
> again and suddenly it had repaired itself and did work.
> 
> So we did read out and discussed a lot of settings and
> everything was fine and the modem appeared to work.
> 
> Until last week where it stopped again.
> 
> But then I tried another script from (/root/wwan-status)
> which does the rfkill unblock but immediately sends first
> AT commands to the modem and echoes the result to the screen.
> 
> This time I did get two commands and then an ^SBC: Overvoltage
> message and the module turned off.
> 
> So this was a hint on what is going on!
> 
> With help of the "/root/charger" script it was possible
> to measure voltage levels inside the Pyra. And indeed,
> VSYS was ca. 4.35V. VSYS ist the main power supply inside
> the Pyra.
> 
> Studying the PLS8 data sheet revealed that the PLS8 is
> indeed specified for 4.2V only. And a small sentence says
> that it issues an overvoltage warning and shuts down if
> power is 100mV above these 4.2V. I.e. it will of course
> shut down in this situation with VSYS being 4.35V.
> 
> Now why can VSYS be 4.35V on a Pyra which is powered from
> a 4.2V LiIon battery? The battery was fully charged and
> showed 4.19V.
> 
> But the USB charging cable was also connected.
> 
> The explanation was again a small note in the bq24297 data
> sheet that in case of a full battery, i.e. charging has
> ended, *and* the usb power is available, that VSYS can go
> up to 150mV above the battery voltage.
> 
> So this explains why we get the 4.35V (? 4.20V + 0.150V)...
> And only in this situation.
> 
> Why didn't we notice it earlier?
> 
> 1. I rarely operate the Pyra prototype with full battery
>   and charger connected. Either the battery is in use
>   or the charger...
> 2. it looks as if almsot nobody has really turned on the
>   PLS8 for extensive tests. So the combination of full
>   battery, charger connected and trying to turn on the
>   PLS8 wasn't encountered so far.
> 3. the information required to recognize this mismatch
>   is distributed over several places in two data sheets,
>   so that we simply overlooked it.
> 
> Now, most important is the question what we can do.
> 
> Well, we can't silence or ignore the overvoltage
> message and shutdown. We also can not reprogram the
> voltage limit for good reasons: this is a safety
> feature to protect the PLS8 from damage.
> 
> Finally, it turned out that we can reduce the maximum
> charging voltage when the charger thinks the battery
> is full and stops. If we lower this to 4.050V we get
> a VSYS of 4.20V max. which does no longer send the PLS8
> into self-shutdown mode...
> 
> Implementing this was a change to the device tree and
> another patch for the bq24297 driver to read the property,
> do some calculation and write the control register.
> 
> And extensive testing.
> 
> I now have the PLS8 up and running for a full day and
> plugged/unplugged the charger several times to catch
> all modes and it was stable and did not even emit an
> overvoltage warning.
> 
> Well, a minor drawback is that the battery isn't charged
> to full 4.2V, but it is preferred anyways not to charge
> it to its maximum to extend its lifetime.
> 
> So we have found a compromise that safes the PLS8
> and the battery from potentially damaging voltages.
> 
> With this fix, this issue seems to be fixed. It is not
> yet in letux-4.18 kernel but will be in letux-4.19-rc1
> and I plan to backport it to letux-4.18.x. Maybe some
> older as well, if tehre are not too many code conflicts.
> 
> So I hope you enjoyed this story and will also have fun
> playing with your PLS8 AT commands (if your Pyra has one
> installed and after you have installed a patched kernel).
> 
> BR,
> Nikolaus
> 
> 
> This seems like something that the EDA should have been able to catch.

Yes, I agree, but not every EDA is capable of doing this.

And, unless someone provides the data (written in textual form in the data sheets)
in machine readable format, it can't do any design rule checks.

>  Is there no way to configure the supply side bq24297 can produce a range of voltages and likewise each consumer has some safe range and the EDA would highlight if they don't overlap?

Yes, would be a nice feature for EDA systems, but the one we use isn't capable of doing it.
And it did not know the ba24297 and the PLS8 either, before I added them to the library.

In general, we might have catched it earlier - but it would probably be the same
solution by software.

BR,
Nikolaus



More information about the Letux-kernel mailing list