• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 48 subscribers
  • Views 140 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DAC5571: Bus clear function

Shunsuke Yamamoto
Genius 9661 points

Part Number: DAC5571

Hi team,

Does this device cover bus clear function of I2C? It seems DAC5571 doesn't have bus clear function since there no pins of reset.

image.png

Best regards,

Shunsuke Yamamoto

  • 0
    TI__Genius 9661 points

    Hi team,

    If the clock from MCU to SCL line suddenly stopped during sending the data on SCL line and SDA line, how DAC5571 recognize?

    Best regards,

    Shunsuke Yamamoto

  • 0 in reply to Shunsuke Yamamoto
    TI__Genius 14590 points

    Hi Yamamoto-san,

    This device does not have any I2C clear functionality. If I2C is malfunctioning, you must hardware reset the device.

    If the SCL suddenly stops, the device will wait for the command to finish. The datasheet does not specify any time-out function. 

    Thanks,
    Erin

  • 0 in reply to Shunsuke Yamamoto
    TI__Guru** 100225 points

    Yamamoto-san,


    The DAC5571 does not have a reset pin to reset any of the I2C communications. This section you clipped out from the 3.1.16 Bus Clear comes from the I2C specification. It describes clock out 9 pulses to release the bus. This is a mechanism to clock out any data that might be remaining from the target device and should work with most devices including the DAC5571. As Erin mentioned, the device does have a power-on reset to reset the device, but that requires powering down to reset the I2C bus.

    If the SCL line suddenly stopped in the middle of a transaction, you would need to continue to clock out the byte to release the bus. If the MCU detected that the bus was being held (because the device didn't receive the entire transmission), the MCU would clock out the 9 pulses to release the bus as described in the Bus Clear section.

    Some newer devices have a 25ms - 35ms timeout for the I2C clock. If the bus is static for that period of time, the device will release the I2C bus. This timeout comes from the similar PMBus/SMBus specification, but isn't a true I2C specification.


    Joseph Wu

  • 0 in reply to Joseph Wu
    TI__Genius 9661 points

    Hi Erin-san, Joseph-san,

    Thank you for the reply. I understood totally.

    Joseph Wu said:
    If the SCL line suddenly stopped in the middle of a transaction, you would need to continue to clock out the byte to release the bus. If the MCU detected that the bus was being held (because the device didn't receive the entire transmission), the MCU would clock out the 9 pulses to release the bus as described in the Bus Clear section.

    Regarding the comment above, Is it okay to input the one transaction which start and stop condition are included in instead of inputting clocks on CLK line?

    Best regards,

    Shunsuke Yamamoto

  • +1 in reply to Shunsuke Yamamoto
    TI__Guru** 100225 points

    Yamamoto-san,


    The controller could try to do a START and STOP condition at the beginning and end of the 9 clock cycles. However, the controller does not have control of the bus. The bus is stuck low because the target is controlling the bus.

    You can find this diagram in A Basic Guide to I2C (https://www.ti.com/lit/pdf/sbaa565):

    When the bus is tied up, the SDA is already low. A START begins with SDA going low, and later SCL starting high and then going low. Because the bus is tied up, the START can't happen because the SDA is can't transition low. After sending 9 clock cycles, the target should release the bus. At that point, a STOP condition should be possible. 


    Joseph Wu