i2cdetect -y xx doesn't seem to clear buffer after scanning for i2c devices on MULTIPLE MUX #6039
Comments
|
I think it's worse than you describe, because aren't the |
MUX1 knows nothing about MUX2. Reading the bindings, there is the or 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
Addresses used on the parent bus will also be reserved on all child buses. |
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNULW7PASEBE5XFUUVLYYGYPXAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXGYYDCMRVGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I guess that is required, otherwise there would be no way to say "I want to talk to the parent bus now".
That's already covered by #6037 |
|
#6040 adds an override |
|
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 <#6040> and
rebased #6038 <#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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNUMKWWZBHLB7RV4PZ3YYHBSHAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXG43TMNRWHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
What are your complete dtoverlay lines now?
(aka -2) if correctly configured. |
|
In other words: |
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNRFYB34KAXWHV2ODXTYYHQ77AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJYGAZTOMBUGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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). 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. Memory says it is delete /boot/firmware/.firmware_revision to force rpi-update to download the files again. |
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNXBPMKKKASS4TQIO5DYYHV2DAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJYGEYDANBRGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
The fix is merged into source tree and is in current rpi-update kernel. So it shouldn't be an issue going forward. |
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNT6OGGDB27B4NMYFKTYZQRQZAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGAZDKNJQGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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
> <#6039 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AFQXPNT6OGGDB27B4NMYFKTYZQRQZAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGAZDKNJQGE>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
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
>> <#6039 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AFQXPNT6OGGDB27B4NMYFKTYZQRQZAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGAZDKNJQGE>
>> .
>> You are receiving this because you authored the thread.Message ID:
>> ***@***.***>
>>
>
|
|
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: The active idle_state value should also be available somewhere in sysfs - try: |
|
By the way, it may be possible (as a diagnostic test only) to force the muxes to report or disable the attached buses: where the |
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNX2ZA7KSDAP2RVRW2DY4KVRLAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSHE3TINBWHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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
> <#6039 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AFQXPNX2ZA7KSDAP2RVRW2DY4KVRLAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSHE3TINBWHA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
I think your troubleshooting is good, but the results are showing that the deselection/disconnection is not working. Try accessing both muxes, but with
|
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNSFG2M3FTXL4APFPWTY4KYN3AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGAZTIOJTGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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:
|
|
Alternatively, download a modified version of the i2c-mux overlay from here: https://drive.google.com/file/d/1L8eY0GQVYd6R4926R13td9rcz9igQOj6/view?usp=sharing |
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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
> <#6039 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
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
>> <#6039 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE>
>> .
>> You are receiving this because you authored the thread.Message ID:
>> ***@***.***>
>>
>
|
|
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
>>> <#6039 (comment)>,
>>> or unsubscribe
>>> <https://github.com/notifications/unsubscribe-auth/AFQXPNTVUNS6UAVI5BZLQPTY4LVN7AVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGQ4TQNJQGE>
>>> .
>>> You are receiving this because you authored the thread.Message ID:
>>> ***@***.***>
>>>
>>
|
pelwell
added a commit
to raspberrypi/utils
that referenced
this issue
Apr 15, 2024
Integer values passed as literal cell values are converted to strings along the way. The result is passed to strtoull, which has a right to object to being given a negative input, therefore use %u in the format string rather than %d. See: raspberrypi/linux#6039 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
pull bot
pushed a commit
to Leuca/utils
that referenced
this issue
Apr 16, 2024
Integer values passed as literal cell values are converted to strings along the way. The result is passed to strtoull, which has a right to object to being given a negative input, therefore use %u in the format string rather than %d. See: raspberrypi/linux#6039 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
timg236
added a commit
to timg236/rpi-eeprom
that referenced
this issue
Apr 17, 2024
…same branch * Switch to building the Pi4 firmware from the common Pi4/Pi5 mainline release. This doesn't change the Pi4 features but should make it quicker to release bug fixes in common code. * Fix issue that caused the TRYBOOT flag to be lost in secure-boot mode. * dtoverlay: Use %u when converting u32s to strings See: raspberrypi/linux#6039 * Improved debug messages for secure-boot. * Generate the bootloader diagnostics qrcode at run time.
timg236
added a commit
to raspberrypi/rpi-eeprom
that referenced
this issue
Apr 17, 2024
…same branch * Switch to building the Pi4 firmware from the common Pi4/Pi5 mainline release. This doesn't change the Pi4 features but should make it quicker to release bug fixes in common code. * Fix issue that caused the TRYBOOT flag to be lost in secure-boot mode. * dtoverlay: Use %u when converting u32s to strings See: raspberrypi/linux#6039 * Improved debug messages for secure-boot. * Generate the bootloader diagnostics qrcode at run time.
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this issue
Apr 17, 2024
See: raspberrypi/linux#6062 firmware: arm_dt: Improve power HAT+ support firmware: arm_loader: Add user otp read and write functions See: raspberrypi/linux#6014 firmware: dtoverlay: Use %u when converting u32s to strings See: raspberrypi/linux#6039 firmware: video_decode: CONFIGCHANGED not wanted with lack of aspect ratio in new frame See: https://forum.libreelec.tv/thread/28391-cvideoplayeraudio-process-stream-stalled/?postID=190597#post190597
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this issue
Apr 17, 2024
See: raspberrypi/linux#6062 firmware: arm_dt: Improve power HAT+ support firmware: arm_loader: Add user otp read and write functions See: raspberrypi/linux#6014 firmware: dtoverlay: Use %u when converting u32s to strings See: raspberrypi/linux#6039 firmware: video_decode: CONFIGCHANGED not wanted with lack of aspect ratio in new frame See: https://forum.libreelec.tv/thread/28391-cvideoplayeraudio-process-stream-stalled/?postID=190597#post190597
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNQALVRC5JXFBEZJG7DY4L22DAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGU2TSNRSHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
You shouldn't need to install it any more - just install the latest stable firmware: |
|
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
<#6039 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNWSICX3SQBQXSMS3TLY63CZXAVCNFSM6AAAAABEWFKCQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTGQZDGNJSGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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 - |
|
My advice was showing its age - the preferred syntax is now |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 3xthe first time, it correctly looks for all the available devices on bus 3x (MUX1). But, when I then typei2cdetect -y 4yto 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:
57 and 68 do not exist on bus 40...
Steps to reproduce the behaviour
1- install 2 identical MUX via dtoverlay:
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, stage4Helios@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/LinuxLogs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: