pirelli dp-l10 stuck

Aw: pirelli dp-l10 stuck

Re: Aw: pirelli dp-l10 stuck

Re: Aw: pirelli dp-l10 stuck

Hi,

On 24.08.2014 14:33, TSAREGORODTSEV, Yury wrote:
> I didn't specify details because everything working properly,
> beside its just stuck while running mobile application probably during
> cell sync.
> Its not charger case, its something different.

Which branch are you using?

Make sure you have the following commit in your branch:
http://cgit.osmocom.org/osmocom-bb/commit/?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e

Regards,
Steve

Re: Aw: pirelli dp-l10 stuck

Hi Steve,
tried master and jolly/handover
anyway my gcc: 4.7.2 (debian wheezy)

Yury

----- Original Message -----
From: "Steve Markgraf" <steve@steve-m.de>
To: "Yury TSAREGORODTSEV" <yury@bridgecommunication.co.uk>, "Richard Menedetter" <ricsi@gmx.at>
Cc: baseband.devel@lists.osmocom.org
Sent: Sunday, August 24, 2014 2:59:49 PM
Subject: Re: Aw: pirelli dp-l10 stuck

Hi,

On 24.08.2014 14:33, TSAREGORODTSEV, Yury wrote:
> I didn't specify details because everything working properly,
> beside its just stuck while running mobile application probably during
> cell sync.
> Its not charger case, its something different.

Which branch are you using?

Make sure you have the following commit in your branch:
http://cgit.osmocom.org/osmocom-bb/commit/?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e

Regards,
Steve

Re: Aw: pirelli dp-l10 stuck

Re: Aw: pirelli dp-l10 stuck

Re: Aw: pirelli dp-l10 stuck

"TSAREGORODTSEV, Yury" <yury@bridgecommunication.co.uk> wrote:

> Damn, yeah 
> its not charging at all :) 
> even when connected to hub with external power :) 

Unfortunately there are no schematics available for the DP-L10 (and
reconstructing them from steve-m's PCB layer scans is anything but
easy), so everything that follows is ultimately pure guesswork, but it
*seems* to me that the battery charging circuit in this phone is
fundamentally the same as in the more traditional Calypso+Iota phones
(Compal etc), aside from using USB VBUS as the charging power source
instead of a dedicated round-plug type of power jack.

If the charging circuit in the DP-L10 works the way I think it does,
following common sense and all that, than the battery charging process
ought to be controlled by Iota ABB.  The ABB chip in this phone is
TWL3014, but I'll use the more readable TWL3025 datasheet as a
reference instead - back in 2011 both Steve M. and Sylvain M. said on
this list that the two chips are functionally identical.

The battery charging functionality is described on pages 46-48 of
TWL3025_SWRS021.pdf; in particular, refer to Figure 4-10 on page 48.
If my understanding of this datasheet description is correct, and if
the phone in question (Pirelli DP-L10) indeed has its battery charging
circuit implemented in the canonical way, then one of the following
two conditions must be met in order for charging current to pass from
VBUS into the battery:

1. The "precharge" function is enabled inside the ABB chip, such that
an internal transistor in the ABB opens up to pass some current from
the VCHG pin to the PCHG pin.  This precharge function is intended for
situation when the battery has discharged so low that it needs to be
charged some before one can boot the CPU, hence this precharge phase
has to be done entirely in hardware without any CPU firmware
supervision.  But it appears that this hardware-only precharge function
is automatically disabled when the CPU is turned on, or maybe the
precharge current is so feeble that the drain from the running CPU is
greater than the amount of power coming from the precharge circuit.

-or-

2. The "normal" way of charging the battery (with the CPU running) is
for the CPU to enable the main charging circuit in the ABB via some
register writes.  In this case the power flows from the charging source
(USB VBUS in the case of Pirelli DP-L10) into the battery through an
external power transistor controlled by the ICTL output from the ABB.

In TI's standard firmware the battery charging function lives in the
PWR SWE (RiViera Software Entity) in the older versions and in the LCC
SWE in newer ones.  Pirelli's version appears to use PWR rather than
LCC.  We (the world public) have the source for the PWR SWE in the
MV100 find, and that for LCC in the Sotovik find, but I haven't really
looked at either of them yet - working on L1 integration currently.

If you would like to get Pirelli battery charging working in OsmocomBB,
I would recommend that you take the charging code for compal_e88,
enable it for the DP-L10 build, and experiment from there.  Don't be
fooled by Pirelli's use of USB charging instead of a round-plug
charger, my guess is that they use USB VBUS in exactly the same way as
how Compal etc use their charging power source.

It also seems to me that Pirelli's charging mechanism does not strictly
comply with the USB spec.  Per the spec, you are supposed to draw no
more than 100 mA from VBUS until and unless you negotiate a higher
power budget with the host, and that negotiation takes place over the
D+ and D- wires.  But in Pirelli's case these D+ and D- wires go to
the CP2102 USB-serial chip and nowhere else, and only this CP2102
speaks the USB protocol - the Calypso only sees UART-serial on the
other side of the CP2102.  So they "illegally" tap VBUS (which per the
spec must not go anywhere but to the device that speaks the USB
protocol) to use it as the charging power source, but have no way to
negotiate their current draw.

When Pirelli's fw detects the presence of VBUS via the charger-insert
interrupt from the ABB and decides to start charging the battery, it
has no choice but to enable some hard-coded charging current value -
the charging current can be adjusted by programming a register in the
ABB, but the fw has no way of knowing how much current it is allowed
to draw from VBUS, if any at all, because only the USB logic in the
CP2102 has access to this knowledge.  So whatever charging current it
draws, it must do so blindly.  I can only guess that this current must
be somewhere around 500 mA, as charging at 100 mA would be too slow.

I actually like Pirelli's design in this regard, and I currently plan
on copying it in my own Pirelli-inspired Calypso dumbphone design: put
a CP2102 inside the phone just like Pirelli did, and use the same USB
charging arrangement, drawing 500 mA for charging unconditionally,
showing "the middle finger" to the developer-unfriendly Unusable
Serial Botch specs...  Or can someone think of a better way?

VLR,
SF

Re: Aw: pirelli dp-l10 stuck

Well,
accordingly to specs more or less everything same,
i have few phones and ready to say goodbye to them :)
but as i never been guru as so many guys here i dunno what kind of changes to do in code,
as anyway c123 doesn't use usb at all, so unfortunately code should be modified anyway,
if someone can do it I am gladly gonna be tester :)

Yury

----- Original Message -----
From: "Michael Spacefalcon" <msokolov@ivan.Harhan.ORG>
To: baseband.devel@lists.osmocom.org
Sent: Sunday, August 24, 2014 11:05:29 PM
Subject: Re: Aw: pirelli dp-l10 stuck

"TSAREGORODTSEV, Yury" <yury@bridgecommunication.co.uk> wrote:

> Damn, yeah 
> its not charging at all :) 
> even when connected to hub with external power :) 

Unfortunately there are no schematics available for the DP-L10 (and
reconstructing them from steve-m's PCB layer scans is anything but
easy), so everything that follows is ultimately pure guesswork, but it
*seems* to me that the battery charging circuit in this phone is
fundamentally the same as in the more traditional Calypso+Iota phones
(Compal etc), aside from using USB VBUS as the charging power source
instead of a dedicated round-plug type of power jack.

If the charging circuit in the DP-L10 works the way I think it does,
following common sense and all that, than the battery charging process
ought to be controlled by Iota ABB.  The ABB chip in this phone is
TWL3014, but I'll use the more readable TWL3025 datasheet as a
reference instead - back in 2011 both Steve M. and Sylvain M. said on
this list that the two chips are functionally identical.

The battery charging functionality is described on pages 46-48 of
TWL3025_SWRS021.pdf; in particular, refer to Figure 4-10 on page 48.
If my understanding of this datasheet description is correct, and if
the phone in question (Pirelli DP-L10) indeed has its battery charging
circuit implemented in the canonical way, then one of the following
two conditions must be met in order for charging current to pass from
VBUS into the battery:

1. The "precharge" function is enabled inside the ABB chip, such that
an internal transistor in the ABB opens up to pass some current from
the VCHG pin to the PCHG pin.  This precharge function is intended for
situation when the battery has discharged so low that it needs to be
charged some before one can boot the CPU, hence this precharge phase
has to be done entirely in hardware without any CPU firmware
supervision.  But it appears that this hardware-only precharge function
is automatically disabled when the CPU is turned on, or maybe the
precharge current is so feeble that the drain from the running CPU is
greater than the amount of power coming from the precharge circuit.

-or-

2. The "normal" way of charging the battery (with the CPU running) is
for the CPU to enable the main charging circuit in the ABB via some
register writes.  In this case the power flows from the charging source
(USB VBUS in the case of Pirelli DP-L10) into the battery through an
external power transistor controlled by the ICTL output from the ABB.

In TI's standard firmware the battery charging function lives in the
PWR SWE (RiViera Software Entity) in the older versions and in the LCC
SWE in newer ones.  Pirelli's version appears to use PWR rather than
LCC.  We (the world public) have the source for the PWR SWE in the
MV100 find, and that for LCC in the Sotovik find, but I haven't really
looked at either of them yet - working on L1 integration currently.

If you would like to get Pirelli battery charging working in OsmocomBB,
I would recommend that you take the charging code for compal_e88,
enable it for the DP-L10 build, and experiment from there.  Don't be
fooled by Pirelli's use of USB charging instead of a round-plug
charger, my guess is that they use USB VBUS in exactly the same way as
how Compal etc use their charging power source.

It also seems to me that Pirelli's charging mechanism does not strictly
comply with the USB spec.  Per the spec, you are supposed to draw no
more than 100 mA from VBUS until and unless you negotiate a higher
power budget with the host, and that negotiation takes place over the
D+ and D- wires.  But in Pirelli's case these D+ and D- wires go to
the CP2102 USB-serial chip and nowhere else, and only this CP2102
speaks the USB protocol - the Calypso only sees UART-serial on the
other side of the CP2102.  So they "illegally" tap VBUS (which per the
spec must not go anywhere but to the device that speaks the USB
protocol) to use it as the charging power source, but have no way to
negotiate their current draw.

When Pirelli's fw detects the presence of VBUS via the charger-insert
interrupt from the ABB and decides to start charging the battery, it
has no choice but to enable some hard-coded charging current value -
the charging current can be adjusted by programming a register in the
ABB, but the fw has no way of knowing how much current it is allowed
to draw from VBUS, if any at all, because only the USB logic in the
CP2102 has access to this knowledge.  So whatever charging current it
draws, it must do so blindly.  I can only guess that this current must
be somewhere around 500 mA, as charging at 100 mA would be too slow.

I actually like Pirelli's design in this regard, and I currently plan
on copying it in my own Pirelli-inspired Calypso dumbphone design: put
a CP2102 inside the phone just like Pirelli did, and use the same USB
charging arrangement, drawing 500 mA for charging unconditionally,
showing "the middle finger" to the developer-unfriendly Unusable
Serial Botch specs...  Or can someone think of a better way?

VLR,
SF