Skip to main content
R
Rushali
Graduate
February 5, 2024
Solved

After configuring STM32H747I I2C with I2C peripheral(PCF8575)receiving a high pulse

  • February 5, 2024
  • 1 reply
  • 2343 views

When I configured development board's I2C I am receiving a short high pulse at 8th clock of SCL.I am attaching the waveform on scope following this post.

Thanking in advance.

 

    This topic has been closed for replies.
    Best answer by tjaekel

    Sure, changing to a different slave device might look different.
    As TDK has mentioned: you are concerned about a pulse which does not matter (it should not have any effect).

    As mentioned:

    • a signal on SDA can change any time - even with a pulse generated - as long as the SCK is low
    • if SCK is high - SDA is not "allowed" to change - you should never see a pulse on SDA when SCK is high
      (except for START and STOP bit which is a "violation" of this rule, but with intent)

    I have checked again your scope picture: I guess, you are talking about the small spikes on SDA (during the transaction), after the 8th bit, right?

    But pretty obvious for me (what I see) and not any issue:

    • your pulses on SDA happen always after 8 bits sent (before the 9th bit)
    • the 9th bit is turning the direction, so that slave can send the ACK bit
    • I2C is Open Drain logic: so, if a master releases the bus, so that a slave can drive now SDA - SDA becomes floating (now an input on master side)
    • but because of pull-up - the SDA wants to change to high signal, and it does in your case, for a very short period of time
    • now the slave drives SDA towards the master: it sends the ACK - which is a low bit:
      the SDA is pulled low, after pull-up tried to pull it high - this is your pulse
    • there is a tiny period where the SDA signal is floating, it wants to go high, the slave is a bit slow in sending ACK - which is actually a good sign (it avoids a driver conflict) - completely "legal" what you see

    The SDA "must" generate such pulses - on the 9th bit (due to Open Drain logic and "speed" of the slave). Changing to a different slave is a different timing: the other guy is now faster on driving SDA as ACK towards the master and the pulse disappears.

    As long as you see "pulses" during SCK is low - all is fine. And such pulses are obvious to get on the 9th bit.

    Your "pulses" (on scope picture) should not have any effect (and they are possible and based on the nature how I2C works, dependent on the slave device you use...). All fine!

    1 reply

    T
    TDK
    Super User
    February 5, 2024

    There is nothing wrong with that signal. The pulse is due to a switch on which chip that is driving that signal for the ACK bit.

    T
    tjaekel
    Visitor II
    February 6, 2024

    Are we talking about bit 9?

    Bit 9 is an ACK/NACK: if all is OK, bit 9 is low. If something goes wrong, e.g. wrong I2C slave address (and not any slave is responding) bit 9 is high.

    When you say "short high pulse" - remember this:

    • I2C is Open Drain logic
    • it needs pull-ups
    • if nobody is driving a signal (tying it low) - it goes "automatically" to high level

    So, when on the 9th bit the direction changes (the slave wants to set it ACK, going low) - there can be a small pulse seeing at high short before.

    You have to bear in mind:

    • the signals are only valid when I2C SCK is high (it is sampled with raising edge).
    • if a signal, e.g. SDA toggles, e.g. for the 9th bits (sending an ACK/NACK) - it can go high during the period when SCK is still low.
    • ignore all transitions on SDA when SCK is low (it is not valid, no meaning: except for START and STOP bits)

    Just look for SDA line when SCK is high (ignore transitions on SDA during SCK low). This can be caused by "changing the direction" and the pull-ups there (causing a high pulse which is not "valid" for master and should be ignored).

    R
    RushaliAuthor
    Graduate
    February 7, 2024

    Dear tjaekel,

    Thanks for replying.But didn't notice any kind of false pulse when i changed the I2C Peripheral.

     

    Terms & ConditionsAccessibility statement