Why the below i2c frame decode as “0x18 0x44 0x00 0x00” rather than “0x30 0x88 0x00 0x00”
@robin_hsieh Could you try the workarounds linked below? I suspect our I2C analyzer is decoding addresses as 7-bit values, while you are expecting it to decode as 8-bit values.
Aside from your decoding issue, it look s like you could use a lower value pull up resistor on your clock and data lines. The signal rise times look very slow.
1 Like
My i2c speed is 400k. If change the sample rate of Logic Pro 16 from 500Ms/s into 6.25Ms/s, the problem is disappear.
That’s fine for decoding the signal with the logic analyzer, but you may find your system is unreliable with such slow edges. Notice that the rising edge on the clock only just makes it back up to your rail voltage on each clock cycle. The same issue is present on your data lines. I am somewhat surprised that your I2C communication is working at all!
2 Likes
@P.Jaquiery There is an Anti-aliasing filter (as discussed at length in another post) that could make the analog waveforms (incorrectly) look like this (in 99% of the time I’d immediately agree with you - this looks marginal at best).
@robin_hsieh can you confirm if the analog signal waveform looks more square-waved and it rises to high-level ‘well’ with the 500MHz (really 50MHz analog) sampling rate vs the 6.25MHz rate?
At 500 MS/s, zoom in to see if any glitches (short pulses) on the digital waveform. Lowering the sample rate can essentially filter out or de-glitch any high-frequency noise on the bus.
Meanwhile, @P.Jaquiery makes a good point that your I2C bus doesn’t look very good from an analog signal quality – which could be the cause of your glitches in the digital decoder.
See: https://www.nxp.com/docs/en/user-guide/UM10204.pdf section 7.1 Pull-up resistor sizing for details, as it depends on electrical characteristics of your design (supply voltage, bus capacitance, etc.)
I2C waveforms are typically more rounded than other ‘push-pull’ type serial interfaces, as the open drain/open collector pins use a weaker pull-up than an I/O port that is actively driven high. However, your analog capture looks like the pull-ups might be “too weak” (or too much bus capacitance) and the design might be risking more than just logic analyzer decoder errors in the future.
On this waveform, it doesn’t look impacted by anti-aliasing (AA) filter, as the “shark fin” peaks look pretty sharp. If AA filtering was affecting it, then you would have a more rounded (sinusoidal) look, and possibly losing amplitude – but this signal looks like it is reaching the same voltage levels as the idle phase. The data line also seems to have some cross-talk with the clock line, as the high levels appear to be disturbed at clock edges, too.
Was the logic analyzer properly grounded when connecting to the target? (I.e., connecting an all black wire that isn’t CH0 or CH8 input). For clocked signals, I tend to connect the GND associated with the highest frequency – so I’d suggest the SCL channel’s ground line in this case. You definitely want at least one ground connection other than the USB ground for better signal integrity.
1 Like
Yeah, I’d reduce the pull-up resistance by at least a factor of 3. Maybe even 10x lower.
1 Like