I have some weird I2C2 SCL clock issue. Please see attached oscillogram.
Digital chn 0 and analogue chn 1 is I2C2 SCL signal
Digital chn 1 - I2C2 SDA
Digital chn 2 - one of VIU3 pixel data inputs
Digital chn 3 - VIU3 HSYNC input
Digital chn 5 - VIU3 PIXEL_CLK input
It seems SCL high pulse can be abandoned by VIU3 pixel data. No matter what's pixel clock, is it 10MHz or 40MHz, SCL still may get broken. I have 3rd party CMOS camera module attached to TVR-VF65GS10 card. This camera module for some reason passes SCL through integrating RC circuit with R=22 Ohm, C=680pF. That's why SCL rising edges are quite round. Issue persists even if I reduce SCL frequency to <10kHz (which I think should make rising time relatively short to be relevant). Luckily I have workaround for this problem, making SCL pin fully driven and not open drain solves the issue.
What's worse, once such short SCL pulse is generated, I2C module seems entering some weird state. For example sometimees I see bus busy in status register, though I2C and SCL both are idling high and MSSL=0.
Am I wrong in thinking that once I2C wins arbitration, nothing on SCL or SDA should be able to shorten SCL-high pulses. Isn't it? SCL-low can be stretched by slave device, but SCL-high shouldn't be affected, right?
If it matters here's connection list:
// cmos_pixclk pci_primary_a8 ptb15
// cmos_hsync pci_primary_b40 ptb6 ? J23 remove jumper from pin 4, SCI2_TX; or keep unused
// cmos_vsync pci_primary_b39 ptb7 J24 remove jumper from pin 4, SCI2_RX; or keep unused
// cmos_d0 pci_primary_a19 ptc3
// cmos_d1 pci_primary_a20 ptc4
// cmos_d2 pci_primary_b13 ptc5
// cmos_d3 pci_primary_b19 ptc6
// cmos_d4 pci_primary_b20 ptc7
// cmos_d5 pci_primary_b46 ptb19
// cmos_d6 pci_primary_b44 ptb20
// cmos_d7 pci_primary_b45 ptb21
// cmos_d9 pci_primary_a22 pta16 don't enable trace d0 14
// cmos_d9 pci_primary_a39 ptb1 yellow LED 19
// cmos_d10 pci_primary_a38 ptb2 yel/grn LED
// cmos_d11 pci_primary_a37 ptb3 or/red LED 21
I2C2 SCL PTA22
I2C2 SDA PTA23