i2cdetect -y xx doesn't seem to clear buffer after scanning for i2c devices on MULTIPLE MUX

[Trilife]

Describe the bug

I have 2 MUX installed, as follows: dtoverlay=i2c-mux,pca9548,addr=0x74,base=40 dtoverlay=i2c-mux,pca9548,addr=0x70,base=30 (note base=xx is a beta provided by PhilE, but the problem was there before this).

When I type i2cdetect -y 3x the first time, it correctly looks for all the available devices on bus 3x (MUX1). But, when I then type i2cdetect -y 4y to show devices on bus 4y (MUX2), it superimposes what it found on bus 3x to what it finds on 4y. If my interpretation is correct, it holds onto the buffer from MUX1 when displaying MUX2.

It doesn't do this, when you stick to MUX1 addresses. Only superimposes MUX1 onto MUX2. I tested the reverse, with MUX2 first and MUX1 second. Same behavior.

Example:

Helios@HeliosRPi4:~ $ i2cdetect -y 30
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: UU -- -- -- UU -- -- --
Helios@HeliosRPi4:~ $ i2cdetect -y 40
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- 28 -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: UU -- -- -- UU -- -- --
Helios@HeliosRPi4:~ $

57 and 68 do not exist on bus 40...

Steps to reproduce the behaviour

1- install 2 identical MUX via dtoverlay:

dtoverlay=i2c-mux,pca9548,addr=0x74
dtoverlay=i2c-mux,pca9548,addr=0x70

2- install a few i2c devices on each MUX, ideally different I2C addresses 3- reboot 4- type 'i2cdetect -y xx' (MUX1) and note the devices shown on monitor 5- type 'i2cdetect -y yy' (MUX2) and note that the devices shown from the previous step (port XX) are still visible, in addition to the actual devices on port YY.

Device (s)

Raspberry Pi 4 Mod. B

System

Helios@HeliosRPi4:~ $ cat /etc/rpi-issue Raspberry Pi reference 2023-12-05 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 70cd6f2a1e34d07f5cba7047aea5b92457372e05, stage4 Helios@HeliosRPi4:~ $ vcgencmd version Oct 17 2023 15:39:16 Copyright (c) 2012 Broadcom version 30f0c5e4d076da3ab4f341d88e7d505760b93ad7 (clean) (release) (start) Helios@HeliosRPi4:~ $ uname -a Linux HeliosRPi4 6.6.21-v8+ #1 SMP PREEMPT Thu Mar 14 10:53:16 UTC 2024 aarch64 GNU/Linux

Logs

No response

Additional context

No response

[pelwell]

I think it's worse than you describe, because aren't the UUs in 70: UU -- -- -- UU -- -- -- the PCF9548s themselves?

[6by9]

I have 2 MUX installed, as follows:

dtoverlay=i2c-mux,pca9548,addr=0x74,base=40
dtoverlay=i2c-mux,pca9548,addr=0x70,base=30 

(note base=xx is a beta provided by PhilE, but the problem was there before this).

When I type i2cdetect -y 3x the first time, it correctly looks for all the available devices on bus 3x (MUX1). But, when I then type i2cdetect -y 4y to show devices on bus 4y (MUX2), it superimposes what it found on bus 3x to what it finds on 4y. If my interpretation is correct, it holds onto the buffer from MUX1 when displaying MUX2.

It doesn't do this, when you stick to MUX1 addresses. Only superimposes MUX1 onto MUX2. I tested the reverse, with MUX2 first and MUX1 second. Same behavior.

MUX1 knows nothing about MUX2. By default the mux is left selected to the last used output in the hope that it saves reselecting the same output for the next transaction. So your observation is correct - activating a 3x output and then a 4x output will see the combination of the two mux output buses.

Reading the bindings, there is the i2c-mux-idle-disconnect or idle-state properties that allow control of the idle state of any mux. Adding either

i2c-mux-idle-disconnect;

or

idle-state = <MUX_IDLE_DISCONNECT>;

to the pca95x nodes should cause it to always disconnect when idle, at the expense of an extra I2C write to the mux after every transaction (this will add up for something like an i2cdetect).

I think it's worse than you describe, because aren't the UUs in 70: UU -- -- -- UU -- -- -- the PCF9548s themselves?

Addresses used on the parent bus will also be reserved on all child buses.

[Trilife]

Hi Phil;

Correct, UU are the MUX addresses of the PCA9548s. Seems like it would make sense that when i2cdetect scans the bus, it would see both 0x70 and 0x74.

BTW, is it possible that the mod you made to add base= to the i2c-mux broke the GPIO edge detection:

I get this error, after I installed it: GPIO.add_event_detect(self.input_pin, GPIO.BOTH, callback=self._rising_or_falling, bouncetime=200) RuntimeError: Failed to add edge detection.

New to RPi. Please advise, if this is the correct venue for this type of conversation.

Cheers.

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Thu, 14 Mar 2024 at 09:34, Phil Elwell @.***> wrote:

I think it's worse than you describe, because aren't the UUs in 70: UU -- -- -- UU -- -- -- the PCF9548s themselves?

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-1997601256, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNULW7PASEBE5XFUUVLYYGYPXAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXGYYDCMRVGY . You are receiving this because you authored the thread.Message ID: @.***>

[pelwell]

Addresses used on the parent bus will also be reserved on all child buses.

I guess that is required, otherwise there would be no way to say "I want to talk to the parent bus now".

BTW, is it possible that the mod you made to add base= to the i2c-mux broke the GPIO edge detection:

I get this error, after I installed it:

GPIO.add_event_detect(self.input_pin, GPIO.BOTH,
callback=self._rising_or_falling, bouncetime=200)
RuntimeError: Failed to add edge detection.

That's already covered by https://github.com/raspberrypi/linux/issues/6037

[6by9]

6040 adds an override disconnect_on_idle that adds idle-state = <MUX_IDLE_DISCONNECT>; to the relevant nodes.

[pelwell]

I've merged #6040 and rebased #6038 on top of it. As usual, it will take about 45 minutes for the auto-builds to complete, then sudo rpi-update pulls/6038 again. (If you installed pulls/6040 instead you would lose the base= parameter support)

[Trilife]

Hi Phil;

I did the update #6038 again, after a 2hr wait. It still ghosts the devices on the first MUX, when polling the second one.

@.:~ $ i2cdetect -y 30 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: UU -- -- -- UU -- -- -- @.:~ $ i2cdetect -y 40 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: UU -- -- -- UU -- -- -- , 57 and 68 shouldn't be on bus 40.

cheers

ᐧ

On Thu, 14 Mar 2024 at 10:52, Phil Elwell @.***> wrote:

I've merged #6040 https://github.com/raspberrypi/linux/pull/6040 and rebased #6038 https://github.com/raspberrypi/linux/pull/6038 on top of it. As usual, it will take about 45 minutes for the auto-builds to complete, then sudo rpi-update pulls/6038 again. (If you installed pulls/6040 instead you would lose the base= parameter support)

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-1997776668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNUMKWWZBHLB7RV4PZ3YYHBSHAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXG43TMNRWHA . You are receiving this because you authored the thread.Message ID: @.***>

[6by9]

What are your complete dtoverlay lines now? Have you added the disconnect_on_idle override to both of them?

xxd /proc/device-tree/soc/i2c@7e804000/mux@70/idle-state should return

00000000: ffff fffe

(aka -2) if correctly configured.

[pelwell]

In other words:

dtoverlay=i2c-mux,pca9548,addr=0x74,base=40,disconnect_on_idle
dtoverlay=i2c-mux,pca9548,addr=0x70,base=30,disconnect_on_idle

[Trilife]

I had not added disconnect_on_idle, but I did so now and rebooted. Config.txt looks like this: ' [all] dtoverlay=w1-gpio dtoverlay=i2c-mux,pca9548,addr=0x70,base=30,disconnect_on_idle dtoverlay=i2c-mux,pca9548,addr=0x74,base=40,disconnect_on_idle '.

After the reboot, I still get ghosting.

BTW, xxd @.**@./idle-state -bash: xxd: command not found

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Thu, 14 Mar 2024 at 13:03, Phil Elwell @.***> wrote:

In other words:

dtoverlay=i2c-mux,pca9548,addr=0x74,base=40,disconnect_on_idle dtoverlay=i2c-mux,pca9548,addr=0x70,base=30,disconnect_on_idle

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-1998037040, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNRFYB34KAXWHV2ODXTYYHQ77AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJYGAZTOMBUGA . You are receiving this because you authored the thread.Message ID: @.***>

[6by9]

I can't find my PCA9548 at present, but I've done a quick hack to the driver to ignore I2C errors, and used I2C event logging (see https://riptutorial.com/linux-kernel/example/11983/tracing-i2c-events for how)

My log (plus annotations) gives me this as a fragment from an i2cdetect -y 29 (8th bus on the mux as I haven't got the base_nr patches).

Write 0 bytes to address 0x72 on bus 29
       i2cdetect-2334    [001] ..... 12005.787266: i2c_write: i2c-29 #0 a=072 f=0000 l=0 []

Write 1 byte to set the mux to port 8
       i2cdetect-2334    [001] ..... 12005.787268: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [80]
       i2cdetect-2334    [001] ..... 12005.787409: i2c_result: i2c-1 n=1 ret=-5

Write 0 bytes to address 0x72 on bus 1 (parent of bus 29)
       i2cdetect-2334    [001] ..... 12005.787411: i2c_write: i2c-1 #0 a=072 f=0000 l=0 []
       i2cdetect-2334    [001] ..... 12005.787550: i2c_result: i2c-1 n=1 ret=-121

Set the mux to no output
       i2cdetect-2334    [001] ..... 12005.787552: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [00]
       i2cdetect-2334    [001] ..... 12005.787690: i2c_result: i2c-1 n=1 ret=-5

Overall write failed
       i2cdetect-2334    [001] ..... 12005.787692: i2c_result: i2c-29 n=1 ret=-121

Write 0 bytes to address 0x73 on bus 29
       i2cdetect-2334    [001] ..... 12005.787725: i2c_write: i2c-29 #0 a=073 f=0000 l=0 []

Set the mux to port 8
       i2cdetect-2334    [001] ..... 12005.787727: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [80]
       i2cdetect-2334    [001] ..... 12005.787867: i2c_result: i2c-1 n=1 ret=-5

Write 0 bytes to address 0x73 on bus 1 (parent of bus 29)
       i2cdetect-2334    [001] ..... 12005.787870: i2c_write: i2c-1 #0 a=073 f=0000 l=0 []
       i2cdetect-2334    [001] ..... 12005.788009: i2c_result: i2c-1 n=1 ret=-121

Set the mux to no output
       i2cdetect-2334    [001] ..... 12005.788011: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [00]
       i2cdetect-2334    [001] ..... 12005.788151: i2c_result: i2c-1 n=1 ret=-5

Overall write failed
       i2cdetect-2334    [001] ..... 12005.788153: i2c_result: i2c-29 n=1 ret=-121

So that is doing exactly what I'd expect it to.

rpi-update normally caches the build that it last installed. I don't know whether it does so with pulls, but it's possible that it didn't update to the new build. If that has happened, then sudo vclog -m will report the fact it has been ignored, eg from dtoverlay=i2c-mux,pca9548,wibble

005904.876: Loaded overlay 'i2c-mux'
005904.891: dtparam: pca9548=true
005905.568: dtparam: wibble=true
005910.874: Unknown dtparam 'wibble' - ignored

Memory says it is delete /boot/firmware/.firmware_revision to force rpi-update to download the files again.

[Trilife]

Greetings,

So I got caught up in the RPi.GPIO snafu, took me a while to fix it (problem was with my ven setup).

In the meantime, I did a sudo apt upgrade, and lo and behold pull #6039 disappeared from my Rpi 4.

I had to install it again (and again it didn't install the disconnect_on_idle).

The "disconnect" feature isn't critical to my application, it only affects i2cdetect, as far as I can tell.

But, is there a time frame when #6038 will become parto of the regular upgrade? Not yet familiar with how this works...

And, in the meantime is there a fix around the upgrade breaking my setup at every iteration?

I appreciate your continued support!

On Thu, Mar 14, 2024, 13:44 6by9 @.***> wrote:

I can't find my PCA9548 at present, but I've done a quick hack to the driver to ignore I2C errors, and used I2C event logging (see https://riptutorial.com/linux-kernel/example/11983/tracing-i2c-events for how)

My log (plus annotations) gives me this as a fragment from an i2cdetect -y 29 (8th bus on the mux as I haven't got the base_nr patches).

Write 0 bytes to address 0x72 on bus 29 i2cdetect-2334 [001] ..... 12005.787266: i2c_write: i2c-29 #0 a=072 f=0000 l=0 []

Write 1 byte to set the mux to port 8 i2cdetect-2334 [001] ..... 12005.787268: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [80] i2cdetect-2334 [001] ..... 12005.787409: i2c_result: i2c-1 n=1 ret=-5

Write 0 bytes to address 0x72 on bus 1 (parent of bus 29) i2cdetect-2334 [001] ..... 12005.787411: i2c_write: i2c-1 #0 a=072 f=0000 l=0 [] i2cdetect-2334 [001] ..... 12005.787550: i2c_result: i2c-1 n=1 ret=-121

Set the mux to no output i2cdetect-2334 [001] ..... 12005.787552: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [00] i2cdetect-2334 [001] ..... 12005.787690: i2c_result: i2c-1 n=1 ret=-5

Overall write failed i2cdetect-2334 [001] ..... 12005.787692: i2c_result: i2c-29 n=1 ret=-121

Write 0 bytes to address 0x73 on bus 29 i2cdetect-2334 [001] ..... 12005.787725: i2c_write: i2c-29 #0 a=073 f=0000 l=0 []

Set the mux to port 8 i2cdetect-2334 [001] ..... 12005.787727: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [80] i2cdetect-2334 [001] ..... 12005.787867: i2c_result: i2c-1 n=1 ret=-5

Write 0 bytes to address 0x73 on bus 1 (parent of bus 29) i2cdetect-2334 [001] ..... 12005.787870: i2c_write: i2c-1 #0 a=073 f=0000 l=0 [] i2cdetect-2334 [001] ..... 12005.788009: i2c_result: i2c-1 n=1 ret=-121

Set the mux to no output i2cdetect-2334 [001] ..... 12005.788011: i2c_write: i2c-1 #0 a=070 f=0000 l=1 [00] i2cdetect-2334 [001] ..... 12005.788151: i2c_result: i2c-1 n=1 ret=-5

Overall write failed i2cdetect-2334 [001] ..... 12005.788153: i2c_result: i2c-29 n=1 ret=-121

So that is doing exactly what I'd expect it to.

rpi-update normally caches the build that it last installed. I don't know whether it does so with pulls, but it's possible that it didn't update to the new build. If that has happened, then sudo vclog -m will report the fact it has been ignored, eg from dtoverlay=i2c-mux,pca9548,wibble

005904.876: Loaded overlay 'i2c-mux' 005904.891: dtparam: pca9548=true 005905.568: dtparam: wibble=true 005910.874: Unknown dtparam 'wibble' - ignored

Memory says it is delete /boot/firmware/.firmware_revision to force rpi-update to download the files again.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-1998100410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNXBPMKKKASS4TQIO5DYYHV2DAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJYGEYDANBRGA . You are receiving this because you authored the thread.Message ID: @.***>

[popcornmix]

And, in the meantime is there a fix around the upgrade breaking my setup at every iteration?

The fix is merged into source tree and is in current rpi-update kernel. It will be in subsequent updates to apt kernel. You won't get overwritten unless there is an update (or you request install --reinstall).

So it shouldn't be an issue going forward.

[Trilife]

Greetings,

Sorry for the prolonged absence. Guests in town.

Over the last couple of days I've been struggling with I2C and MUXs. More on that in a bit.

1- I upgraded to the latest RPi OS this morning. As @popcornmix mentioned, indeed the 6038 is downloading correctly.

3- Before I upgraded the OS, I deleted /boot/firmware/.firmware_revision as @6by9 mentioned, so the new 6038 loads properly.

3- However, the ghosting is still present, despite my adding 'disconnect_on_idle' to both MUXs' dtoverlay: [all] dtoverlay=w1-gpio dtoverlay=i2c-mux,pca9548,addr=0x70,base=30,disconnect_on_idle dtoverlay=i2c-mux,pca9548,addr=0x74,base=40,disconnect_on_idle

4- I then ran a sudo rpi-update pulls/6038 and rebooted, hoping to see ghosting disappear. Ghosting persists!

Now to my new problem: I have two MUXs on SDA1/SCL1 with addresses/bases as seen above.They have pressure sensors on them, all with an I2C address of 0x28. I can read one or many sensors on 0x70's OR!! 0x74's buses successfully. But the moment I try switch MUX it stops reading, UNTIL I DO A SHUTDOWN. I tried:

a) hard resetting the MUX's via their !RESET lines. No good b) powering down the MUXs and the sensors. No good c) reversing the order x74 first, x70 first. It hangs up either way d) reboot instead of shutdown. No good

I can start with 0x74, add and subtract sensors to it without a problem. Same with 0x70.

But the moment I switch from one MUX to the other, it stops reading properly. NO ERROR messages, just stops reading correct data.

Here is the code I am using for the test:

import smbus2 import time

def main(): bus40 = None bus41 = None bus37 = None

try:
    while True:
        # bus40 = smbus2.SMBus(40)
        # try:
        #     pressure_bytes = bus40.read_i2c_block_data(0x28, 0, 4)
        #     time.sleep(0.1)
        #     pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
        #     pressure = round((10.972 * (pressure_raw - 1638) *

25 / 13110), 2)

print(f'Balance Tank Pressure Bytes:

{pressure_bytes[0]} {pressure_bytes[1]} raw: {pressure_raw} clean: {pressure}')

except Exception as e:

        #     print(e)
        # #bus40.close()
        # time.sleep(1)
        #
        bus41 = smbus2.SMBus(41)
        try:
            pressure_bytes = bus41.read_i2c_block_data(0x28, 0, 4)
            time.sleep(.1)
            pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
            pressure = round((10.972 * (pressure_raw - 1638) * 25

/ 13110), 2) print(f'House Tank Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]} raw: {pressure_raw} clean: {pressure}') except Exception as e: print(e) bus41.close() time.sleep(1)

        bus37 = smbus2.SMBus(32)
        try:
            pressure_bytes = bus37.read_i2c_block_data(0x28, 0, 4)
            time.sleep(.1)
            pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
            pressure = round((0.01 * (pressure_raw - 1638) * 400 /

13110), 2) print(f'Filter Pressure Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]} raw: {pressure_raw} clean: {pressure}') except Exception as e: print(e) bus37.close() time.sleep(1)

        print()
except KeyboardInterrupt:
    bus40.close()
    bus41.close()
    bus37.close()
    print("Keyboard Interrupt")

if name == 'main': main()

I tried bus.close() after every reading, but that didn't help. I tried opening and closing the buses with every reading. Didn't help I tried opening the buses at the beginning and keeping them open until CTRL-C. didn't help. I added delays. Didn't help

Can anyone help me with this please?

Cheers

ᐧ

On Fri, 22 Mar 2024 at 07:43, popcornmix @.***> wrote:

And, in the meantime is there a fix around the upgrade breaking my setup at every iteration?

The fix is merged into source tree and is in current rpi-update kernel. It will be in subsequent updates to apt kernel. You won't get overwritten unless there is an update (or you request install --reinstall).

So it shouldn't be an issue going forward.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2015025501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNT6OGGDB27B4NMYFKTYZQRQZAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGAZDKNJQGE . You are receiving this because you authored the thread.Message ID: @.***>

[Trilife]

forgot to add this:

@.:~ $ i2cdetect -l i2c-1 i2c bcm2835 @.) I2C adapter i2c-20 i2c fef04500.i2c I2C adapter i2c-21 i2c fef09500.i2c I2C adapter i2c-30 i2c i2c-1-mux (chan_id 0) I2C adapter i2c-31 i2c i2c-1-mux (chan_id 1) I2C adapter i2c-32 i2c i2c-1-mux (chan_id 2) I2C adapter i2c-33 i2c i2c-1-mux (chan_id 3) I2C adapter i2c-34 i2c i2c-1-mux (chan_id 4) I2C adapter i2c-35 i2c i2c-1-mux (chan_id 5) I2C adapter i2c-36 i2c i2c-1-mux (chan_id 6) I2C adapter i2c-37 i2c i2c-1-mux (chan_id 7) I2C adapter i2c-40 i2c i2c-1-mux (chan_id 0) I2C adapter i2c-41 i2c i2c-1-mux (chan_id 1) I2C adapter i2c-42 i2c i2c-1-mux (chan_id 2) I2C adapter i2c-43 i2c i2c-1-mux (chan_id 3) I2C adapter i2c-44 i2c i2c-1-mux (chan_id 4) I2C adapter i2c-45 i2c i2c-1-mux (chan_id 5) I2C adapter i2c-46 i2c i2c-1-mux (chan_id 6) I2C adapter i2c-47 i2c i2c-1-mux (chan_id 7) I2C adapter @.***:~ $

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Fri, 5 Apr 2024 at 18:27, Jean-Robert Strele @.***> wrote:

Greetings,

Sorry for the prolonged absence. Guests in town.

Over the last couple of days I've been struggling with I2C and MUXs. More on that in a bit.

1- I upgraded to the latest RPi OS this morning. As @popcornmix mentioned, indeed the 6038 is downloading correctly.

3- Before I upgraded the OS, I deleted /boot/firmware/.firmware_revision as @6by9 mentioned, so the new 6038 loads properly.

3- However, the ghosting is still present, despite my adding 'disconnect_on_idle' to both MUXs' dtoverlay: [all] dtoverlay=w1-gpio dtoverlay=i2c-mux,pca9548,addr=0x70,base=30,disconnect_on_idle dtoverlay=i2c-mux,pca9548,addr=0x74,base=40,disconnect_on_idle

4- I then ran a sudo rpi-update pulls/6038 and rebooted, hoping to see ghosting disappear. Ghosting persists!

Now to my new problem: I have two MUXs on SDA1/SCL1 with addresses/bases as seen above.They have pressure sensors on them, all with an I2C address of 0x28. I can read one or many sensors on 0x70's OR!! 0x74's buses successfully. But the moment I try switch MUX it stops reading, UNTIL I DO A SHUTDOWN. I tried:

a) hard resetting the MUX's via their !RESET lines. No good b) powering down the MUXs and the sensors. No good c) reversing the order x74 first, x70 first. It hangs up either way d) reboot instead of shutdown. No good

I can start with 0x74, add and subtract sensors to it without a problem. Same with 0x70.

But the moment I switch from one MUX to the other, it stops reading properly. NO ERROR messages, just stops reading correct data.

Here is the code I am using for the test:

import smbus2 import time

def main(): bus40 = None bus41 = None bus37 = None

try:
    while True:
        # bus40 = smbus2.SMBus(40)
        # try:
        #     pressure_bytes = bus40.read_i2c_block_data(0x28, 0, 4)
        #     time.sleep(0.1)
        #     pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
        #     pressure = round((10.972 * (pressure_raw - 1638) * 25 / 13110), 2)
        #     print(f'Balance Tank Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]} raw: {pressure_raw}  clean: {pressure}')
        # except Exception as e:
        #     print(e)
        # #bus40.close()
        # time.sleep(1)
        #
        bus41 = smbus2.SMBus(41)
        try:
            pressure_bytes = bus41.read_i2c_block_data(0x28, 0, 4)
            time.sleep(.1)
            pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
            pressure = round((10.972 * (pressure_raw - 1638) * 25 / 13110), 2)
            print(f'House Tank Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]}  raw: {pressure_raw}  clean: {pressure}')
        except Exception as e:
            print(e)
        bus41.close()
        time.sleep(1)

        bus37 = smbus2.SMBus(32)
        try:
            pressure_bytes = bus37.read_i2c_block_data(0x28, 0, 4)
            time.sleep(.1)
            pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
            pressure = round((0.01 * (pressure_raw - 1638) * 400 / 13110), 2)
            print(f'Filter Pressure Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]} raw: {pressure_raw}  clean: {pressure}')
        except Exception as e:
            print(e)
        bus37.close()
        time.sleep(1)

        print()
except KeyboardInterrupt:
    bus40.close()
    bus41.close()
    bus37.close()
    print("Keyboard Interrupt")

if name == 'main': main()

I tried bus.close() after every reading, but that didn't help. I tried opening and closing the buses with every reading. Didn't help I tried opening the buses at the beginning and keeping them open until CTRL-C. didn't help. I added delays. Didn't help

Can anyone help me with this please?

Cheers

ᐧ

On Fri, 22 Mar 2024 at 07:43, popcornmix @.***> wrote:

And, in the meantime is there a fix around the upgrade breaking my setup at every iteration?

The fix is merged into source tree and is in current rpi-update kernel. It will be in subsequent updates to apt kernel. You won't get overwritten unless there is an update (or you request install --reinstall).

So it shouldn't be an issue going forward.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2015025501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNT6OGGDB27B4NMYFKTYZQRQZAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGAZDKNJQGE . You are receiving this because you authored the thread.Message ID: @.***>

[Trilife]

And further information:

Trying to read from another MUX also seems to foul up other I2C devices. I tested a INA219 current sensor. Works fine when I read it on the first MUX, but once I try reading any device on the 2nd MUX, output becomes gibberish. No going back to the first MUX. Need a SHUTDOWN.

When I say gibberish, the serial data is there and stable, no errors. It just is not a reflection of the pressure/current/voltage applied.

Saludos, Regards,

Jean-Robert STRELE COL +57.321.414.6328 USA +1.925.922.4231 @.***

On Fri, Apr 5, 2024, 18:29 Jean-Robert Strele @.***> wrote:

forgot to add this:

@.:~ $ i2cdetect -l i2c-1 i2c bcm2835 @.) I2C adapter i2c-20 i2c fef04500.i2c I2C adapter i2c-21 i2c fef09500.i2c I2C adapter i2c-30 i2c i2c-1-mux (chan_id 0) I2C adapter i2c-31 i2c i2c-1-mux (chan_id 1) I2C adapter i2c-32 i2c i2c-1-mux (chan_id 2) I2C adapter i2c-33 i2c i2c-1-mux (chan_id 3) I2C adapter i2c-34 i2c i2c-1-mux (chan_id 4) I2C adapter i2c-35 i2c i2c-1-mux (chan_id 5) I2C adapter i2c-36 i2c i2c-1-mux (chan_id 6) I2C adapter i2c-37 i2c i2c-1-mux (chan_id 7) I2C adapter i2c-40 i2c i2c-1-mux (chan_id 0) I2C adapter i2c-41 i2c i2c-1-mux (chan_id 1) I2C adapter i2c-42 i2c i2c-1-mux (chan_id 2) I2C adapter i2c-43 i2c i2c-1-mux (chan_id 3) I2C adapter i2c-44 i2c i2c-1-mux (chan_id 4) I2C adapter i2c-45 i2c i2c-1-mux (chan_id 5) I2C adapter i2c-46 i2c i2c-1-mux (chan_id 6) I2C adapter i2c-47 i2c i2c-1-mux (chan_id 7) I2C adapter @.***:~ $

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Fri, 5 Apr 2024 at 18:27, Jean-Robert Strele @.***> wrote:

Greetings,

Sorry for the prolonged absence. Guests in town.

Over the last couple of days I've been struggling with I2C and MUXs. More on that in a bit.

1- I upgraded to the latest RPi OS this morning. As @popcornmix mentioned, indeed the 6038 is downloading correctly.

3- Before I upgraded the OS, I deleted /boot/firmware/.firmware_revision as @6by9 mentioned, so the new 6038 loads properly.

3- However, the ghosting is still present, despite my adding 'disconnect_on_idle' to both MUXs' dtoverlay: [all] dtoverlay=w1-gpio dtoverlay=i2c-mux,pca9548,addr=0x70,base=30,disconnect_on_idle dtoverlay=i2c-mux,pca9548,addr=0x74,base=40,disconnect_on_idle

4- I then ran a sudo rpi-update pulls/6038 and rebooted, hoping to see ghosting disappear. Ghosting persists!

Now to my new problem: I have two MUXs on SDA1/SCL1 with addresses/bases as seen above.They have pressure sensors on them, all with an I2C address of 0x28. I can read one or many sensors on 0x70's OR!! 0x74's buses successfully. But the moment I try switch MUX it stops reading, UNTIL I DO A SHUTDOWN. I tried:

a) hard resetting the MUX's via their !RESET lines. No good b) powering down the MUXs and the sensors. No good c) reversing the order x74 first, x70 first. It hangs up either way d) reboot instead of shutdown. No good

I can start with 0x74, add and subtract sensors to it without a problem. Same with 0x70.

But the moment I switch from one MUX to the other, it stops reading properly. NO ERROR messages, just stops reading correct data.

Here is the code I am using for the test:

import smbus2 import time

def main(): bus40 = None bus41 = None bus37 = None

try:
    while True:
        # bus40 = smbus2.SMBus(40)
        # try:
        #     pressure_bytes = bus40.read_i2c_block_data(0x28, 0, 4)
        #     time.sleep(0.1)
        #     pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
        #     pressure = round((10.972 * (pressure_raw - 1638) * 25 / 13110), 2)
        #     print(f'Balance Tank Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]} raw: {pressure_raw}  clean: {pressure}')
        # except Exception as e:
        #     print(e)
        # #bus40.close()
        # time.sleep(1)
        #
        bus41 = smbus2.SMBus(41)
        try:
            pressure_bytes = bus41.read_i2c_block_data(0x28, 0, 4)
            time.sleep(.1)
            pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
            pressure = round((10.972 * (pressure_raw - 1638) * 25 / 13110), 2)
            print(f'House Tank Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]}  raw: {pressure_raw}  clean: {pressure}')
        except Exception as e:
            print(e)
        bus41.close()
        time.sleep(1)

        bus37 = smbus2.SMBus(32)
        try:
            pressure_bytes = bus37.read_i2c_block_data(0x28, 0, 4)
            time.sleep(.1)
            pressure_raw = (pressure_bytes[0] << 8 | pressure_bytes[1])
            pressure = round((0.01 * (pressure_raw - 1638) * 400 / 13110), 2)
            print(f'Filter Pressure Pressure Bytes: {pressure_bytes[0]} {pressure_bytes[1]} raw: {pressure_raw}  clean: {pressure}')
        except Exception as e:
            print(e)
        bus37.close()
        time.sleep(1)

        print()
except KeyboardInterrupt:
    bus40.close()
    bus41.close()
    bus37.close()
    print("Keyboard Interrupt")

if name == 'main': main()

I tried bus.close() after every reading, but that didn't help. I tried opening and closing the buses with every reading. Didn't help I tried opening the buses at the beginning and keeping them open until CTRL-C. didn't help. I added delays. Didn't help

Can anyone help me with this please?

Cheers

ᐧ

On Fri, 22 Mar 2024 at 07:43, popcornmix @.***> wrote:

And, in the meantime is there a fix around the upgrade breaking my setup at every iteration?

The fix is merged into source tree and is in current rpi-update kernel. It will be in subsequent updates to apt kernel. You won't get overwritten unless there is an update (or you request install --reinstall).

So it shouldn't be an issue going forward.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2015025501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNT6OGGDB27B4NMYFKTYZQRQZAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGAZDKNJQGE . You are receiving this because you authored the thread.Message ID: @.***>

[pelwell]

If you can access either mux successfully after a reboot but not then use the other then the deselection is not working (unless the problem is power related).

@6by9 has given you some debug tools that allow you to confirm that the latest driver and overlay are installed:

$ xxd /proc/device-tree/soc/i2c@7e804000/mux@70/idle-state
$ sudo vclog -m

The active idle_state value should also be available somewhere in sysfs - try:

$ find /sys -name idle_state

[pelwell]

By the way, it may be possible (as a diagnostic test only) to force the muxes to report or disable the attached buses:

$ i2cget -f -y 1 0x70
$ i2cset -f -y 1 0x70 0

where the -f flag forces the accesses, even though a kernel driver is using the address.

[Trilife]

Thanks Phil;

Not sure I'm doing this trouble shooting right.

@.***:~ $ cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0074/idle_state -1 It shows '-1' for both MUXes, while they are working (only accessing one) and when they are not (accessing another, even once).

@.:~ $ sudo hexedit @*.**@*.*** /idle-state 00000000 FF FF FF FF .... 0000001C 00000038 00000054 00000070 0000008C 000000A8 000000C4 000000E0 000000FC 00000118 00000134 00000150 0000016C 00000188 000001A4 000001C0 000001DC 000001F8 00000214 00000230 0000024C 00000268 00000284 000002A0 000002BC 000002D8 000002F4 00000310 0000032C 00000348 00000364 -%% idle-state --0x0/0x4--0%-----------------------------------------------------------------------------------------------

I think 'hexedit' is the same as 'xxd', correct? Same output for @. as @.

ᐧ

On Mon, 8 Apr 2024 at 09:54, Phil Elwell @.***> wrote:

By the way, it may be possible (as a diagnostic test only) to force the muxes to report or disable the attached buses:

$ i2cget -f -y 1 0x70 $ i2cset -f -y 1 0x70 0

where the -f flag forces the accesses, even though a kernel driver is using the address.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2042974468, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNX2ZA7KSDAP2RVRW2DY4KVRLAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSHE3TINBWHA . You are receiving this because you authored the thread.Message ID: @.***>

[Trilife]

BTW,

sudo vclog -m shows all dtparams loading well: ' 008948.010: Loaded overlay 'w1-gpio' 009003.308: brfs: File read: 1036 bytes 009012.864: brfs: File read: /mfs/sd/overlays/i2c-mux.dtbo 009067.101: Loaded overlay 'i2c-mux' 009067.123: dtparam: pca9548=true 009068.113: dtparam: addr=0x70 009071.060: dtparam: base=30 009074.273: dtparam: disconnect_on_idle=true 009166.626: brfs: File read: 3412 bytes 009168.457: brfs: File read: /mfs/sd/overlays/i2c-mux.dtbo 009223.277: Loaded overlay 'i2c-mux' 009223.298: dtparam: pca9548=true 009224.287: dtparam: addr=0x74 009227.255: dtparam: base=40 009230.449: dtparam: disconnect_on_idle=true '

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 10:08, Jean-Robert Strele @.***> wrote:

Thanks Phil;

Not sure I'm doing this trouble shooting right.

@.***:~ $ cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0074/idle_state -1 It shows '-1' for both MUXes, while they are working (only accessing one) and when they are not (accessing another, even once).

@.:~ $ sudo hexedit @. @.***/idle-state 00000000 FF FF FF FF .... 0000001C 00000038 00000054 00000070 0000008C 000000A8 000000C4 000000E0 000000FC 00000118 00000134 00000150 0000016C 00000188 000001A4 000001C0 000001DC 000001F8 00000214 00000230 0000024C 00000268 00000284 000002A0 000002BC 000002D8 000002F4 00000310 0000032C 00000348 00000364 -%% idle-state --0x0/0x4--0%-----------------------------------------------------------------------------------------------

I think 'hexedit' is the same as 'xxd', correct? Same output for @. as @.

ᐧ

On Mon, 8 Apr 2024 at 09:54, Phil Elwell @.***> wrote:

By the way, it may be possible (as a diagnostic test only) to force the muxes to report or disable the attached buses:

$ i2cget -f -y 1 0x70 $ i2cset -f -y 1 0x70 0

where the -f flag forces the accesses, even though a kernel driver is using the address.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2042974468, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNX2ZA7KSDAP2RVRW2DY4KVRLAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSHE3TINBWHA . You are receiving this because you authored the thread.Message ID: @.***>

[pelwell]

I think your troubleshooting is good, but the results are showing that the deselection/disconnection is not working. Try accessing both muxes, but with i2cset -f -y 1 0x70 0 and/or i2cset -f -y 1 0x74 0 in between.

hexdump is probably closer to xxd, or use od:

$ od -An -td4 --endian=big /proc/device-tree/soc/i2c@7e804000/mux@70/idle-state

[Trilife]

Ok,

Here is what I did:

1-shutdown system 2- access @. (successful) 3- i2cset -f -y 1 0x70 0 -AND- 0x74 4- access @. (successful!!!) 5- tried accessing both muxes in sequence (FAIL)

BTW, hexdump returns (for both MUX): 0000000 ffff ffff 0000004

OD returns (for both MUX): -1

Installed XXD. It returns for both (after the above FAIL): 00000000 fff fff ....

I also tried modifying config.txt and try the previous settings (without the base and disconnect args). It seems that it now REQUIRES 'base'. 'disconnect_when_idle' is optional.

So, set dtoverlay without disconnect_when_idle and tried accessing both muxes consecutively. It failed.

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 10:18, Phil Elwell @.***> wrote:

I think your troubleshooting is good, but the results are showing that the deselection/disconnection is not working. Try accessing both muxes, but with i2cset -f -y 1 0x70 0 and/or i2cset -f -y 1 0x74 0 in between.

hexdump is probably closer to xxd, or use od:

$ od -An -td4 --endian=big @.**@./idle-state

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2043034931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNSFG2M3FTXL4APFPWTY4KYN3AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGAZTIOJTGE . You are receiving this because you authored the thread.Message ID: @.***>

[pelwell]

Something strange is happening when the firmware is applying the overlay - the idle-state value is coming through as -1 instead of -2. For now, try applying the overlays at runtime:

1. Comment out the config.txt dtoverlay=i2c-mux lines.
2. Sometime after booting but before using the I2C muxes, run this:

   sudo dtoverlay i2c-mux pca9548 addr=0x70 base=30 disconnect_on_idle
   sudo dtoverlay i2c-mux pca9548 addr=0x74 base=40 disconnect_on_idle

[pelwell]

Alternatively, download a modified version of the i2c-mux overlay from here: https://drive.google.com/file/d/1L8eY0GQVYd6R4926R13td9rcz9igQOj6/view?usp=sharing It uses a different way of encoding the same changes that avoids the problem (which I think is due to a difference in the C library used in the firmware).

[Trilife]

Thanks Phil;

I just had a major doozie: Cracked the SD Card while switching housings! I use SAMBA/SSH to develop right on the target RPi and hadn't pushed to GIT in quite some time...

I think the only current code I have is what I sent you by email last weekend!

Let me burn a new SD card, set up SAMBA and I'll test your suggestion/s.

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 14:26, Phil Elwell @.***> wrote:

Something strange is happening when the firmware is applying the overlay - the idle-state value is coming through as -1 instead of -2. For now, try applying the overlays at runtime:

1. Comment out the config.txt dtoverlay=i2c-mux lines.
2. Sometime after booting but before using the I2C muxes, run this:

sudo dtoverlay i2c-mux pca9548 addr=0x70 base=30 disconnect_on_idle sudo dtoverlay i2c-mux pca9548 addr=0x74 base=40 disconnect_on_idle

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2043498501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE . You are receiving this because you authored the thread.Message ID: @.***>

[Trilife]

OK,

I lost 8 weeks worth of work, because of fat fingers and too lazy to push. AAARGH.

But, I have Samba up and running and was able to test the code snippet I emailed you last week.

applying the overlays after booting as you suggest in your 1st email, I am able to access both MUXes without a problem. Might try the other method.

in the meantime, I'll use subprocess.run(). It gives me a warning:

• Failed to apply overlay '2_i2c-mux' (kernel)
• Failed to apply overlay '2_i2c-mux' (kernel) But that's fine

After recreating and update/upgrade the OS, I still had to do an rpi-update pulls/6038 in order to set base and disconnect...

In any case, I am set for now. Thanks so much for leading me through this Phil.

I'll be off the forum for a while recreating code....

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 18:01, Jean-Robert Strele @.***> wrote:

Thanks Phil;

I just had a major doozie: Cracked the SD Card while switching housings! I use SAMBA/SSH to develop right on the target RPi and hadn't pushed to GIT in quite some time...

I think the only current code I have is what I sent you by email last weekend!

Let me burn a new SD card, set up SAMBA and I'll test your suggestion/s.

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 14:26, Phil Elwell @.***> wrote:

Something strange is happening when the firmware is applying the overlay

• the idle-state value is coming through as -1 instead of -2. For now, try applying the overlays at runtime:

  1. Comment out the config.txt dtoverlay=i2c-mux lines.
  2. Sometime after booting but before using the I2C muxes, run this:

sudo dtoverlay i2c-mux pca9548 addr=0x70 base=30 disconnect_on_idle sudo dtoverlay i2c-mux pca9548 addr=0x74 base=40 disconnect_on_idle

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2043498501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE . You are receiving this because you authored the thread.Message ID: @.***>

[Trilife]

Hi There;

after the last OS upgrade i2c is on the fritz again!

when try to execute @.***:~ $ sudo dtoverlay i2c-mux pca9548 addr=0x70 base=30 disconnect_on_idle

• Failed to apply overlay '0_i2c-mux' (kernel) @.:~ $ i2cdetect -l i2c-1 i2c bcm2835 @.) I2C adapter i2c-20 i2c fef04500.i2c I2C adapter i2c-21 i2c fef09500.i2c I2C adapter @.***:~ $

It give me an error and doesn't show the new channels.

I even tried to put it back into config.txt (and reboot), but it doesn't work.

I also forced sudo rpi-update pulls/6038 (after deleting the relevant files). No dice

No idea what is going on.

I tried to follow the instructions of https://riptutorial.com/linux-kernel/example/11983/tracing-i2c-events, but the contents of trace remains the same, after trying to execute the dtoverlays and/or trying to access the i2cs:

tracer: nop

#

entries-in-buffer/entries-written: 0/0 #P:4

#

_-----=> irqs-off/BH-disabled

/ _----=> need-resched

| / _---=> hardirq/softirq

|| / _--=> preempt-depth

||| / _-=> migrate-disable

|||| / delay

TASK-PID CPU# ||||| TIMESTAMP FUNCTION

| | | ||||| | |

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 20:11, Jean-Robert Strele @.***> wrote:

OK,

I lost 8 weeks worth of work, because of fat fingers and too lazy to push. AAARGH.

But, I have Samba up and running and was able to test the code snippet I emailed you last week.

applying the overlays after booting as you suggest in your 1st email, I am able to access both MUXes without a problem. Might try the other method.

in the meantime, I'll use subprocess.run(). It gives me a warning:

• Failed to apply overlay '2_i2c-mux' (kernel)
• Failed to apply overlay '2_i2c-mux' (kernel) But that's fine

After recreating and update/upgrade the OS, I still had to do an rpi-update pulls/6038 in order to set base and disconnect...

In any case, I am set for now. Thanks so much for leading me through this Phil.

I'll be off the forum for a while recreating code....

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 18:01, Jean-Robert Strele @.***> wrote:

Thanks Phil;

I just had a major doozie: Cracked the SD Card while switching housings! I use SAMBA/SSH to develop right on the target RPi and hadn't pushed to GIT in quite some time...

I think the only current code I have is what I sent you by email last weekend!

Let me burn a new SD card, set up SAMBA and I'll test your suggestion/s.

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 14:26, Phil Elwell @.***> wrote:

Something strange is happening when the firmware is applying the overlay

• the idle-state value is coming through as -1 instead of -2. For now, try applying the overlays at runtime:

  1. Comment out the config.txt dtoverlay=i2c-mux lines.
  2. Sometime after booting but before using the I2C muxes, run this:

sudo dtoverlay i2c-mux pca9548 addr=0x70 base=30 disconnect_on_idle sudo dtoverlay i2c-mux pca9548 addr=0x74 base=40 disconnect_on_idle

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2043498501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE . You are receiving this because you authored the thread.Message ID: @.***>

[Trilife]

IGNORE!!!

Lose power wire to the MUXES.

So sorry!

ᐧ

On Sat, 13 Apr 2024 at 14:56, Jean-Robert Strele @.***> wrote:

Hi There;

after the last OS upgrade i2c is on the fritz again!

when try to execute @.***:~ $ sudo dtoverlay i2c-mux pca9548 addr=0x70 base=30 disconnect_on_idle

• Failed to apply overlay '0_i2c-mux' (kernel) @.:~ $ i2cdetect -l i2c-1 i2c bcm2835 @.) I2C adapter i2c-20 i2c fef04500.i2c I2C adapter i2c-21 i2c fef09500.i2c I2C adapter @.***:~ $

It give me an error and doesn't show the new channels.

I even tried to put it back into config.txt (and reboot), but it doesn't work.

I also forced sudo rpi-update pulls/6038 (after deleting the relevant files). No dice

No idea what is going on.

I tried to follow the instructions of https://riptutorial.com/linux-kernel/example/11983/tracing-i2c-events, but the contents of trace remains the same, after trying to execute the dtoverlays and/or trying to access the i2cs:

tracer: nop

#

entries-in-buffer/entries-written: 0/0 #P:4

#

_-----=> irqs-off/BH-disabled

/ _----=> need-resched

| / _---=> hardirq/softirq

|| / _--=> preempt-depth

||| / _-=> migrate-disable

|||| / delay

TASK-PID CPU# ||||| TIMESTAMP FUNCTION

| | | ||||| | |

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 20:11, Jean-Robert Strele @.***> wrote:

OK,

I lost 8 weeks worth of work, because of fat fingers and too lazy to push. AAARGH.

But, I have Samba up and running and was able to test the code snippet I emailed you last week.

applying the overlays after booting as you suggest in your 1st email, I am able to access both MUXes without a problem. Might try the other method.

in the meantime, I'll use subprocess.run(). It gives me a warning:

• Failed to apply overlay '2_i2c-mux' (kernel)
• Failed to apply overlay '2_i2c-mux' (kernel) But that's fine

After recreating and update/upgrade the OS, I still had to do an rpi-update pulls/6038 in order to set base and disconnect...

In any case, I am set for now. Thanks so much for leading me through this Phil.

I'll be off the forum for a while recreating code....

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 18:01, Jean-Robert Strele @.***> wrote:

Thanks Phil;

I just had a major doozie: Cracked the SD Card while switching housings! I use SAMBA/SSH to develop right on the target RPi and hadn't pushed to GIT in quite some time...

I think the only current code I have is what I sent you by email last weekend!

Let me burn a new SD card, set up SAMBA and I'll test your suggestion/s.

Saludos, Greetings Jean-Robert STRELE COL: +57.321.414.6328 USA: +1.925.922.4231 @.***

ᐧ

On Mon, 8 Apr 2024 at 14:26, Phil Elwell @.***> wrote:

Something strange is happening when the firmware is applying the overlay - the idle-state value is coming through as -1 instead of -2. For now, try applying the overlays at runtime:

1. Comment out the config.txt dtoverlay=i2c-mux lines.
2. Sometime after booting but before using the I2C muxes, run this:

sudo dtoverlay i2c-mux pca9548 addr=0x70 base=30 disconnect_on_idle sudo dtoverlay i2c-mux pca9548 addr=0x74 base=40 disconnect_on_idle

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2043498501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE . You are receiving this because you authored the thread.Message ID: @.***>

[Trilife]

Hi Phil,

So, I'm slowly recovering from my SD Card meltdown.

Adding the subprocess seems to work, but I have to run them twice it seems and it works after giving me the error message.

Now, how do I go about installing that i2c-mux.dtbo file, which you so kindly provided? It would seem like the better solution than trapping os messages etc

Cheers

ᐧ

On Mon, 8 Apr 2024 at 15:12, Phil Elwell @.***> wrote:

Alternatively, download a modified version of the i2c-mux overlay from here: https://drive.google.com/file/d/1L8eY0GQVYd6R4926R13td9rcz9igQOj6/view?usp=sharing It uses a different way of encoding the same changes that avoids the problem (which I think is due to a difference in the C library used in the firmware).

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2043559629, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNQALVRC5JXFBEZJG7DY4L22DAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGU2TSNRSHE . You are receiving this because you authored the thread.Message ID: @.***>

[pelwell]

You shouldn't need to install it any more - just install the latest stable firmware: sudo rpi-update stable

[Trilife]

Thanks Phil;

So I tried to run the command and get this: @.:~ $ sudo BRANCH=stable rpi-update Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom Performing self-update Relaunching after update *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom FW_REV:17eaa5016855e0af3b5af8d687b1c8756f8cb55c BOOTLOADER_REV: WANT_32BIT:0 WANT_64BIT:1 WANT_PI4:1 WANT_PI5:1 ############################################################## WARNING: This update bumps to rpi-6.6.y linux tree See: https://forums.raspberrypi.com/viewtopic.php?p=2191175

'rpi-update' should only be used if there is a specific reason to do so - for example, a request by a Raspberry Pi engineer or if you want to help the testing effort and are comfortable with restoring if there are regressions.

DO NOT use 'rpi-update' as part of a regular update process. ############################################################## Would you like to proceed? (y/N) Downloading bootloader tools !!! Failed to download rpi-eeprom-update ' I had just done an upgrade this morning, so maybe it is complaining because it already completed the task.

And just to make sure, once this update is installed, I add the dtoverlay lines to config.txt, correct?

Cheers

ᐧ

On Tue, 23 Apr 2024 at 15:52, Phil Elwell @.***> wrote:

You shouldn't need to install it any more - just install the latest stable firmware: sudo BRANCH=stable rpi-update

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6039#issuecomment-2073423526, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQXPNWSICX3SQBQXSMS3TLY63CZXAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTGQZDGNJSGY . You are receiving this because you authored the thread.Message ID: @.***>

[pelwell]

Hmm, that's a new failure - I'll try and find out what's going wrong. You should be OK with updating to the latest instead - sudo rpi-update.

[pelwell]

My advice was showing its age - the preferred syntax is now sudo rpi-update stable, which works. The BRANCH=stable version is equivalent to sudo rpi-update stable stable, which means "stable software, stable eeprom", and the eeprom has no "stable" branch.