JBL Flip3 is a no-longer supprted bluetooth speaker
the size of a flashlight - sold for <US$100.
Neighbor wanted a smashed USB socket replaced.

36 SCREWS LATER, with a replaced USB socket, the thing
doesn't go, though the usb port draws charging current.
(0.5A reducing after some time to 300mA)

Second (36 SCREWS) time round, after assuring the battery
is fully charged, I hooked everything up, still in the
disassembled state and let the usb charger top up the
battery to 4.17V.

On/off switch is not functional.

When the usb charger is disconnected, the 0/1 button lamp
illuminated white, but did not respond to button presses.

Went through hardware reset and factory reset button
press procedure - 1/0 lamp turns off. No further rssponse
to button pressure.

Inserted USB connector for a second, then removed it.
1/0 indicator turns white, then flashes blue.

I turn on a remote bluetooth source - which sees and
connects to the Flip3.
Flip3 plays the source music with 1/0 indicator
solid blue.

No other indicator lamps illuminate - charge status etc.
but volume controls work.

Pressing 1/0 turns the Flip3 off, but will not restart it.

USB temp insertion/extraction gets the thing back up and
running with the previous BT connection automatically at
previously programmed volume level.

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

All supplies are present and accounted for when churning
out music, but god knows what status lines and their
sequencing or delays are at.

How to get the 0/1 button working - battery status indicators
running again ?

Service manual freely available. https://www.manualslib.com/manual/1843632/Jbl-Flip-3.html#product-FLIP%203

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 06 Sep 2023 13:22:18 -0400, legg <legg@nospam.magma.ca> wrote:

<snip>

Pressing 1/0 turns the Flip3 off, but will not restart it.

A little optomistic here maybe . . . no turn-off from switch
in later trials.

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 06 Sep 2023 13:22:18 -0400, legg <legg@nospam.magma.ca> wrote:

On Wed, 06 Sep 2023 13:22:18 -0400, legg <legg@nospam.magma.ca> wrote:

<snip>

Pressing 1/0 turns the Flip3 off, but will not restart it.

A little optomistic here maybe . . . no turn-off from switch
in later trials.

. . . . but will react to turn off button press five minutes later.

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-06 19:22, legg wrote:

JBL Flip3 is a no-longer supprted bluetooth speaker
the size of a flashlight - sold for <US$100.
Neighbor wanted a smashed USB socket replaced.

...
...

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

All supplies are present and accounted for when churning
out music, but god knows what status lines and their
sequencing or delays are at.

How to get the 0/1 button working - battery status indicators
running again ?

Service manual freely available. https://www.manualslib.com/manual/1843632/Jbl-Flip-3.html#product-FLIP%203

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 6 Sep 2023 20:38:27 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

<snip>

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

I realize that, which is why I mentioned it. Double shorts
being hard to come by . . . .

Remeasuring after hardware/factory reset shows both lines
floating high, now, with no short. The TCA1116 is unobtainium.

Though TI flogs a pin-compatible replacement, they refuse to
supply the original TCA1116 data sheet, for performance, address
and power sequencing comparisons. They will provide the old
data, through email, only to registered users of E2E support.
Why the shyness?

The working white and blue LEDs are driven directly from the
main control chip.

The 0/1 switch feeds a crude SW/HW reinforced latch.

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 6 Sep 2023 20:38:27 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

<snip>

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

Can now see I2C clk and data lines are running when either
the charger is connected or the unit is playing.

The low condition occurs when the charger is disconnected
and the unit is not playing (ie is off). I guess that is
reasonable. . . . silly me. . . . or I could have been
measuring the wrong pins on the wrong IC (it has happened
before).

The volume control switches are routed through the TPS1116
- and THEY are functional. I can see the volume inc and
decrement on the I2C lines in response to a button press
and hear the difference.

. . . . .but the battery capacity indicators and others
(besides the CPU-driven 1/0 white and BT blue connect) are
not being driven from the TPS1116 pins.

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-07 01:49, legg wrote:

On Wed, 6 Sep 2023 20:38:27 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

<snip>

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

Can now see I2C clk and data lines are running when either
the charger is connected or the unit is playing.

The low condition occurs when the charger is disconnected
and the unit is not playing (ie is off). I guess that is
reasonable. . . . silly me. . . . or I could have been
measuring the wrong pins on the wrong IC (it has happened
before).

The volume control switches are routed through the TPS1116
- and THEY are functional. I can see the volume inc and
decrement on the I2C lines in response to a button press
and hear the difference.

. . . . .but the battery capacity indicators and others
(besides the CPU-driven 1/0 white and BT blue connect) are
not being driven from the TPS1116 pins.

RL

So maybe the MCU does not know the battery condition?
Or the measured value is out of spec. Check voltage dividers etc.
Does the charging stop automatically or MCU controlled?
Do you have a USB-USB charge measuring dongle?
(The schematics are mostly unreadable for me).

Arie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 7 Sep 2023 09:56:22 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

On 2023-09-07 01:49, legg wrote:

On Wed, 6 Sep 2023 20:38:27 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

<snip>

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

Can now see I2C clk and data lines are running when either
the charger is connected or the unit is playing.

The low condition occurs when the charger is disconnected
and the unit is not playing (ie is off). I guess that is
reasonable. . . . silly me. . . . or I could have been
measuring the wrong pins on the wrong IC (it has happened
before).

The volume control switches are routed through the TPS1116
- and THEY are functional. I can see the volume inc and
decrement on the I2C lines in response to a button press
and hear the difference.

. . . . .but the battery capacity indicators and others
(besides the CPU-driven 1/0 white and BT blue connect) are
not being driven from the TPS1116 pins.

RL

So maybe the MCU does not know the battery condition?
Or the measured value is out of spec. Check voltage dividers etc.
Does the charging stop automatically or MCU controlled?
Do you have a USB-USB charge measuring dongle?
(The schematics are mostly unreadable for me).

Arie

I'd expect a false battery measurement by MCU to
produce a low battery lamp, or not to run at all,
but will check. OFF lamps are confirmed at TPS1116
output ports, so it's not a harnessing issue.

MCU also looks at USB input voltage. Considering that
turn-on is now triggered by USB removal, it could be
that measurement that's duff.

Battery charging is by MP2637 from USB, without I2C com,
so probably independent, with flags back and forth.
I'm monitoring USB input current flow with a UN34C.

During normal charge input current never exceeds 500mA.
Spends most of its time between 360 and 300mA below
3V9 terminal voltage, reducing gradually to 100mA as
4V exceeded. Bttery capacity 3000mA, so not a quick
charge.

Charging terminates gradually as battery exceeds 4V0 and
approaches 4V17, It's hysteretic (slight audible squeeling
detectable), so not a regulation text book CV charge
termination.

Would be inconvenient for Player to be interrupted by
USB insertion - either charge or play - this is not
likely a normal behavior.

Boost converter MP9428 regulation also seems local - no
I2C with flags. See no issues in the usual power-
handling sections or supply gating switches.

Service manual skinny on normal operation, fault diag
or lamp - button press codes/procedures. I republished
the schematics for view on normal page sizes, but expect
loss of PC text searchability in the results.

Also some cryptic button pushing instructions from
another source.

http://ve3ute.ca/query/flip3.zip

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-07 13:53, legg wrote:

On Thu, 7 Sep 2023 09:56:22 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

On 2023-09-07 01:49, legg wrote:

On Wed, 6 Sep 2023 20:38:27 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

<snip>

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

Can now see I2C clk and data lines are running when either
the charger is connected or the unit is playing.

The low condition occurs when the charger is disconnected
and the unit is not playing (ie is off). I guess that is
reasonable. . . . silly me. . . . or I could have been
measuring the wrong pins on the wrong IC (it has happened
before).

The volume control switches are routed through the TPS1116
- and THEY are functional. I can see the volume inc and
decrement on the I2C lines in response to a button press
and hear the difference.

. . . . .but the battery capacity indicators and others
(besides the CPU-driven 1/0 white and BT blue connect) are
not being driven from the TPS1116 pins.

RL

So maybe the MCU does not know the battery condition?
Or the measured value is out of spec. Check voltage dividers etc.
Does the charging stop automatically or MCU controlled?
Do you have a USB-USB charge measuring dongle?
(The schematics are mostly unreadable for me).

Arie

I'd expect a false battery measurement by MCU to
produce a low battery lamp, or not to run at all,
but will check. OFF lamps are confirmed at TPS1116
output ports, so it's not a harnessing issue.

MCU also looks at USB input voltage. Considering that
turn-on is now triggered by USB removal, it could be
that measurement that's duff.

Battery charging is by MP2637 from USB, without I2C com,
so probably independent, with flags back and forth.
I'm monitoring USB input current flow with a UN34C.

During normal charge input current never exceeds 500mA.
Spends most of its time between 360 and 300mA below
3V9 terminal voltage, reducing gradually to 100mA as
4V exceeded. Bttery capacity 3000mA, so not a quick
charge.

Charging terminates gradually as battery exceeds 4V0 and
approaches 4V17, It's hysteretic (slight audible squeeling
detectable), so not a regulation text book CV charge
termination.

Would be inconvenient for Player to be interrupted by
USB insertion - either charge or play - this is not
likely a normal behavior.

Boost converter MP9428 regulation also seems local - no
I2C with flags. See no issues in the usual power-
handling sections or supply gating switches.

Service manual skinny on normal operation, fault diag
or lamp - button press codes/procedures. I republished
the schematics for view on normal page sizes, but expect
loss of PC text search ability in the results.

Also some cryptic button pushing instructions from
another source.

http://ve3ute.ca/query/flip3.zip

RL

Thanks for the proper diagrams.

I noticed that all problems seem to be with the switches and the battery state LEDs.
In the flip3 indicators diagram those have the GND pin in common. The other LEDs are using VCC.
Could it be that GND in that connection (J11 pin 13 to J9 pin 1) has a bad contact?
That would explain most (all?) problems.
You could solder a jumper wire in parallel from PCB to PCB to test this hypothesis.

Arie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 7 Sep 2023 09:56:22 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

On 2023-09-07 01:49, legg wrote:

On Wed, 6 Sep 2023 20:38:27 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

<snip>

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

Can now see I2C clk and data lines are running when either
the charger is connected or the unit is playing.

The low condition occurs when the charger is disconnected
and the unit is not playing (ie is off). I guess that is
reasonable. . . . silly me. . . . or I could have been
measuring the wrong pins on the wrong IC (it has happened
before).

The volume control switches are routed through the TPS1116
- and THEY are functional. I can see the volume inc and
decrement on the I2C lines in response to a button press
and hear the difference.

. . . . .but the battery capacity indicators and others
(besides the CPU-driven 1/0 white and BT blue connect) are
not being driven from the TPS1116 pins.

RL

So maybe the MCU does not know the battery condition?
Or the measured value is out of spec. Check voltage dividers etc.
Does the charging stop automatically or MCU controlled?
Do you have a USB-USB charge measuring dongle?
(The schematics are mostly unreadable for me).

Arie

I found the trouble - connex were NOT OK - The ribbon cable
to thecharge level display had a broken edge trace for ground
connection.

MCU driven leds werepull-down. Charge display is pull-up.

I frankly didn't see any pulling-up going on at the TSP1116
output ports.

The 0/1 switch now works for both on and off functions.

Good enough for now.

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 7 Sep 2023 14:06:26 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

On 2023-09-07 13:53, legg wrote:

On Thu, 7 Sep 2023 09:56:22 +0200, Arie de Muijnck <noreply@ademu.com>
wrote:

On 2023-09-07 01:49, legg wrote:

On Wed, 6 Sep 2023 20:38:27 +0200, Arie de Muijnck <noreply@ademu.com> >>>> wrote:

<snip>

I see no I2C data traffic to the lamp control IC U2
- both lines pulled low.

That is an illegal state, I2C idle is both lines high.
This indicates a double short, or a bad 16-bit expander.

Can now see I2C clk and data lines are running when either
the charger is connected or the unit is playing.

The low condition occurs when the charger is disconnected
and the unit is not playing (ie is off). I guess that is
reasonable. . . . silly me. . . . or I could have been
measuring the wrong pins on the wrong IC (it has happened
before).

The volume control switches are routed through the TPS1116
- and THEY are functional. I can see the volume inc and
decrement on the I2C lines in response to a button press
and hear the difference.

. . . . .but the battery capacity indicators and others
(besides the CPU-driven 1/0 white and BT blue connect) are
not being driven from the TPS1116 pins.

RL

So maybe the MCU does not know the battery condition?
Or the measured value is out of spec. Check voltage dividers etc.
Does the charging stop automatically or MCU controlled?
Do you have a USB-USB charge measuring dongle?
(The schematics are mostly unreadable for me).

Arie

I'd expect a false battery measurement by MCU to
produce a low battery lamp, or not to run at all,
but will check. OFF lamps are confirmed at TPS1116
output ports, so it's not a harnessing issue.

MCU also looks at USB input voltage. Considering that
turn-on is now triggered by USB removal, it could be
that measurement that's duff.

Battery charging is by MP2637 from USB, without I2C com,
so probably independent, with flags back and forth.
I'm monitoring USB input current flow with a UN34C.

During normal charge input current never exceeds 500mA.
Spends most of its time between 360 and 300mA below
3V9 terminal voltage, reducing gradually to 100mA as
4V exceeded. Bttery capacity 3000mA, so not a quick
charge.

Charging terminates gradually as battery exceeds 4V0 and
approaches 4V17, It's hysteretic (slight audible squeeling
detectable), so not a regulation text book CV charge
termination.

Would be inconvenient for Player to be interrupted by
USB insertion - either charge or play - this is not
likely a normal behavior.

Boost converter MP9428 regulation also seems local - no
I2C with flags. See no issues in the usual power-
handling sections or supply gating switches.

Service manual skinny on normal operation, fault diag
or lamp - button press codes/procedures. I republished
the schematics for view on normal page sizes, but expect
loss of PC text search ability in the results.

Also some cryptic button pushing instructions from
another source.

http://ve3ute.ca/query/flip3.zip

RL

Thanks for the proper diagrams.

I noticed that all problems seem to be with the switches and the battery state LEDs.
In the flip3 indicators diagram those have the GND pin in common. The other LEDs are using VCC.
Could it be that GND in that connection (J11 pin 13 to J9 pin 1) has a bad contact?
That would explain most (all?) problems.
You could solder a jumper wire in parallel from PCB to PCB to test this hypothesis.

Arie

Good Catch. It was the chafed harness edge's ground connection.

The TSP1116 charge level indicators are only active for a short
time after a button press, so it was possible to see no pull-up
action on those output pins and blame the chip.

Thanks for your interest and assistance.

RL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)