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

_______________________________________________
Kernel mailing list
Kernel@pyra-handheld.com
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel