• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 658 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.

HDC2021: I2C timeout

Takashi Onawa
Genius 13200 points
Part Number: HDC2021

Hi Team,

One quick question.

Does HDC2021 support timeout function of I2C? If supported, please let me know the time out period.

I want to know how HDC2021 behave if it cannot receive an ACK/NACK or other response from the I2C MASTER (MCU) during the I2C sequence.

Regards,

Takashi Onawa

  • 0
    TI__Mastermind 28070 points

    Hi Onawa-San,

    I am having our design team check on this. Typically our SMBus compatible sensors do have this timeout feature, but the HDC2x family is only designed for I2C compatibility. I will update you as soon as I am certain.

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    TI__Mastermind 28070 points

    Hi Onawa-San,

    The HDC2x family does not have an I2C timeout. Please let me know if you have any other questions.  

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    TI__Genius 13200 points

    Hi Brandon-san,

    Thanks for your prompt response on this.

    OK, I understood that HDC2X family doesn't have I2C timeout.

    One quick question.

    How does HDC2X behave if it could not get ACK from MCU in command sequence?

    Regards,

    Takashi Onawa

  • 0 in reply to Takashi Onawa
    TI__Mastermind 28070 points

    Hi Onawa-San,

    When the SCL line is still working, the HDC2021 will interpret failure to ACK as a NACK. In the case of a read from the HDC2021, this NACK will tell the HDC2021 to send no more data. 

    If the SCL line is no longer clocking, the HDC2021 must wait for the SCL line to continue before it can take any action. The I2C standard recommends a reset of all devices on the bus in order to fix a stuck SCL line. 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    TI__Genius 13200 points

    Hi Brandon-san,

    Thanks for your prompt reply on this.

    Sorry one quick question.

    >The I2C standard recommends a reset of all devices on the bus in order to fix a stuck SCL line. 

    Regarding the the reset, Is this mean "Appling Stop condition"? Or applying soft and hard reset to all device? 

    Regards,

    Takashi Onawa

  • 0 in reply to Takashi Onawa
    TI__Mastermind 28070 points

    Hi Onawa-San,

    The I2C controller will be the one in charge of SCL (not HDC2021). That line from the I2C standard should only apply for devices capable of holding the SCL line, which the HDC2021 cannot do. So if you see a stuck SCL condition, it is probably due to an issue with the controller or another device on the bus.

    A hard reset is the only method that could recover this. Unless the SCL is recovered, you wouldn't be able to send a soft reset command to the HDC2021.

    Best Regards,

    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    TI__Genius 13200 points

    Hi Brandon-san,

    Thanks for your additional explanation.

    My customer notice that the Master MCU sometimes could not catch the ACK properly due to other heavy processing(it seems that MCU could not react the I2C communication timely), Assuming that SCL gets stuck in the middle of sending an I2C command, will the information in the device's internal FIFO be erased by the Stop Condition? Or will a hard reset of the slave device be required? 

    Regards,

    Takashi Onawa

  • 0 in reply to Takashi Onawa
    TI__Mastermind 28070 points

    Hi Onawa-San,

    If a stop is sent in the middle of the transaction, the HDC2021 should return to a listening state and be ready for the next transaction. Please note that they will have to start the transaction over from the beginning if they send a stop. 

    Best Regards,
    Brandon Fisher