Hey,
we lately experienced some strange behavior with the CM4.
We have a setup consisting of a CM4 where we have connected two MIPI camera-modules, two IO-Expander and a few other ICs (DAC etc.). The two MIPI camera-modules (Sony IMX568) are connected to CSI0 and CSI1 as well as to I2C0 (GPIO 44 / GPIO45) and I2C1/ID (GPIO0 / GPIO1). They are used with the Unicam driver and a custom subdevice driver. Both IO-Expander are connected to I2C4 (GPIO 8 / GPIO 9). The others devices are all connected to I2C3 (GPIO 2 / GPIO 3).
Our startup process is as follows:
1. Load DTOverlay for I2C4
2. Load DTOverlays for both IO-Expander
3. Load DTOverlay for first camera module (I2C 0)
4. Load subdevice driver for the camera modules
5. Load DTOverlay for second camera module (I2C 1)
Steps 3-5 are in this order to probe the camera-modules in a defined manner. The startup process is executed as part of a service-start automatically during/after boot.
In most cases this whole setup works fine and all devices are correctly initialized. However, in some sporadic cases (maybe 1 out of 10 boots) the probing of the first camera module fails. As this is a problem for our use-case, I had a deeper look into this and I examined the I2C signals of the failing sensor with a logic analyzer. When the sensor loading fails I could observe the following strange behavior during one of the first I2C transfers in the probing: At some point in the transfer, when the slave (=sensor) should acknowledge data from the master (=CM4), the SCL line becomes stuck to high for > 5ms. This either upsets the master or the slave leading to a failed transfer and consequently to failed probing of the sensor. In the following you can see pictures showing such a failed transfer.
![Image]()
![Image]()
If SCL would be stuck to low, the behavior could have been explained with clock stretching, but the SCL line stuck to high during a transfer seems to be a fault in my opinion.
I have already spend quite some time searching for people with similar problems. The closest topic I could find is viewtopic.php?t=32482. From there I tested the suggestion of disabling all default I2C traffic (HAT probing, EEPROM writing, camera auto detection) on I2C0 but without any success.
I would really appreciate some help on this.
Thank you!
we lately experienced some strange behavior with the CM4.
We have a setup consisting of a CM4 where we have connected two MIPI camera-modules, two IO-Expander and a few other ICs (DAC etc.). The two MIPI camera-modules (Sony IMX568) are connected to CSI0 and CSI1 as well as to I2C0 (GPIO 44 / GPIO45) and I2C1/ID (GPIO0 / GPIO1). They are used with the Unicam driver and a custom subdevice driver. Both IO-Expander are connected to I2C4 (GPIO 8 / GPIO 9). The others devices are all connected to I2C3 (GPIO 2 / GPIO 3).
Our startup process is as follows:
1. Load DTOverlay for I2C4
2. Load DTOverlays for both IO-Expander
3. Load DTOverlay for first camera module (I2C 0)
4. Load subdevice driver for the camera modules
5. Load DTOverlay for second camera module (I2C 1)
Steps 3-5 are in this order to probe the camera-modules in a defined manner. The startup process is executed as part of a service-start automatically during/after boot.
In most cases this whole setup works fine and all devices are correctly initialized. However, in some sporadic cases (maybe 1 out of 10 boots) the probing of the first camera module fails. As this is a problem for our use-case, I had a deeper look into this and I examined the I2C signals of the failing sensor with a logic analyzer. When the sensor loading fails I could observe the following strange behavior during one of the first I2C transfers in the probing: At some point in the transfer, when the slave (=sensor) should acknowledge data from the master (=CM4), the SCL line becomes stuck to high for > 5ms. This either upsets the master or the slave leading to a failed transfer and consequently to failed probing of the sensor. In the following you can see pictures showing such a failed transfer.
If SCL would be stuck to low, the behavior could have been explained with clock stretching, but the SCL line stuck to high during a transfer seems to be a fault in my opinion.
I have already spend quite some time searching for people with similar problems. The closest topic I could find is viewtopic.php?t=32482. From there I tested the suggestion of disabling all default I2C traffic (HAT probing, EEPROM writing, camera auto detection) on I2C0 but without any success.
I would really appreciate some help on this.
Thank you!
Statistics: Posted by marcp — Thu Mar 28, 2024 5:20 pm — Replies 0 — Views 32