8
\$\begingroup\$

Somewhere around the end of transmitting a byte in Master Transmit mode the following is observed(SCL - yellow, SDA - blue).

enter image description here

I am mainly interested in

  1. What is the tiny pulse on the right? STOP? START? ACK? glitch?

But those clarifications would also help:

  1. Is the non-square clock a reason for concern?
  2. What is the left pulse? It's too early for a STOP so I guess it's a data bit 1. But is it usual to keep the level during SCL==high?
  3. The master is configured for Normal mode 100kBps but the frequency of the clock it emits is 87.4kHz(clock stretching is enabled but not observed). Is that normal?
\$\endgroup\$
3
  • 6
    \$\begingroup\$ Q1: yes. First solve the hardware issue before tackling the protocol. The scope plot suggests that your pullup resistors are too weak. Change them for some value between 1kΩ and 4.7kΩ. \$\endgroup\$
    – Velvet
    Jun 8, 2022 at 9:07
  • \$\begingroup\$ @Seir thank You for the input. It would be rather difficult to change the resistors (I would need to talk to the HW department) but I can reduce the speed. Please elaborate(in an answer) on how critical the clock situation is. \$\endgroup\$
    – Vorac
    Jun 8, 2022 at 9:11
  • 3
    \$\begingroup\$ Clock rise time is specified in the specification. Have the hardware people validate their own mess. See the rising clock line actually pushing the data line to weird shape and above 3.3V supply, and falling edge of clock pulling data slightly negative? That's crosstalk between the wires. Likely a wiring or layout issue. \$\endgroup\$
    – Justme
    Jun 8, 2022 at 20:45

1 Answer 1

12
\$\begingroup\$
  1. The short pulse occurs after the 8th data bit and just before the ACK. It's the point at which the data line changes direction. Whichever device was driving out the data (master for write, slave for read) releases the data line, so it starts to go high. The device at the other end then begins driving the line low to acknowledge (ACK) the data transfer. If there was to be a NACK, the other device would not drive the line low, so it would continue up to the full line voltage and be clocked as a 1 (NACK).

    Because this switchover happens when the clock is low, and in plenty of time before the next rising clock edge, it is completely invisible to the devices on each end so can be ignored.

    The width of the pulse depends largely on the speed of the rising edge and how quickly the responding device reacts to the direction change. I've seen devices which ACK quickly enough that there is no spurious pulse, and other cases where the line reaches full voltage before the ACK is made.


  1. The non-square nature of the signals is due to it being an open-drain bus. The bus is only pulled high by a resistor which has to overcome the parasitic capacitance of the bus lines. This R-C circuit leads to a curving of the rising edge.

    You can make the lines more square by using a lower value pull-up resistor, or alternatively you could use an I2C buffer device to break the line into sections to reduce the parasitic capacitance of each part of the bus.

    Having said that it is quite normal to have some curvature of I2C lines (the resistors can only be so low before devices stuggle to overcome them when driving low). If all of the devices are working normally then there is probably no issue with the slow edges.

  2. The left most pulse will be a data bit. Yes it is completely normal and indeed required for the data line to hold its value while the clock is high. With the exception of a STOP, START, or RESTART condition, the data line must never be changed while the clock is high. As such it will stay at the same value until just after the falling edge of the clock.

    This can be seen in Figure 4 of the I2C Spec, copied below for perpetuity:

    I2C data line can only change when clock is low

  3. Depends on your master - what clock source it is using, how it is generating the SCL signal. It may use a simple clock divider that cannot generate 100kHz for the MCU clock frequency. In practice it doesn't really matter as long as it is in-spec for the devices you are clocking. 88kHz is perfectly reasonable for a 100kHz I2C bus.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Very good answer, honestly always observed this pulse before ACK and never realised the actual reason for it (which is now so obvious!) \$\endgroup\$ Jun 8, 2022 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.