Tool/software:
We have a design with very similar traces that are shown in the linked question. (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1211283/pca9518-smbus-waveform-abnormal-for-pca9518)
The issue was never fully addressed in that thread. Our design does not use a rise time accelerator. Apart from the ESP32 bus master, the devices are all slave devices and do not use clock stretching. The scope traces below are based on 100kHz I2C transactions, although most zoom in on the rising edge where we are seeing the problems. Our PCB has two separate I2C buses. One uses a single PCA9518 hub, and the other uses two of them connected through the EXP pins as shown in the datasheet. I have attached an excerpt of the schematic.
Both I2C trees are driven by an ESP32-S3 chip. We have validated that the buses are being driven properly by disconnecting the hub chips and observing the I2C signals on an oscilloscope - rise time fall time, timing, sequence are all correct.
For the two hub circuit (left sheet above) this is what we see on the SCL0/SDA0 pins.
The spike in the rising edges resemble the problem shown in the inked question. That thread suggests that a rise-time accelerator can cause this, but we do not have one in our design.
One thing we observe is that the spike is present even when no ENx are asserted, and it changes slightly depending on what ENx is asserted.
The spike is transmitted through the hub when it is enabled - here is SCL1 signal corresponding to the right image just above.
The single hub case has similar issues. This shows the waveform at SCL0 when all ENx are asserted and it looks the same when all 4 ENx are deasserted. This waveform corresponds with the datasheet, except for the tiny spike and relaxation at the initial rising edge.
Here are SCL0 and SCL4 of the single hub bus when EN4 is asserted. This time, the glitch did not pass through the device.
Are there any recommendations to fix this circuit?
