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.

HDC2010: Questions surrounding DRDY and RESET

Part Number: HDC2010

Team,

I have a customer designing with HDC2010, and they had several questions surrounding the device:

They are manually triggering the device by writing  0 to addr 0xF. The DS says this bit is said to be auto cleared when measurement is done. Given this, what is the purpose of DRDY bit , bit 7 addr 0x04 in this use case? How does the DRDY bit work with the auto measure, which they can set in bit [6:4] addr 0x0E? For example, let say I set to auto measure to be 5 sample per second, how is the DRDY going to behave? What is not clear to me is for example let say one measure was done and second is start and in between I didn’t read that DRDY will be set due to the first finish but actually we are now in middle of second read.

As you see from above, it is not clear to the customer how the DRDY sequencing is supposed to be used/work. Can you walk through this process?

- They are also not clear what the purpose of the offset is, as the user already needs to do some calculation to get the temp and humidity. Therefore, it is not like the value they read is already final and as such offset can compensate so read is easy. Can they not just calibrate out the offset in the digital realm when they perform the math needed? 

There is a soft reset bit 7 addr 0x0E but it is not cleared when do I need to use it ?

What can cause the chip to stop working and require soft reset ?

Also it said to be auto clear does it mean once it clear I can immediately issue new  I2C access or is there any delay needed and if so how long ?

When using the manual trigger in bit 0 addr 0x0F what happen if a new trigger is issue while the prior one was not finished yet ?

Finally, they believe there is typo, as the reset value in register 0xFC and 0xFD don’t match the 16 bit representation you show for the ID in 7.6.18. Can you share  which one is the correct the representation or the reset.

  • Dear Carolus -
    On the offset question - this is for offsetting any variations they would see after manufacturing - in their final test - they can set these registers up to shift the measurement back to where it is supposed to be in case they altered the device while soldering, cleaning or other contamination sources.

    We do have this application note on programming the HDC2xxx devices: www.ti.com/.../snaa312.pdf
    there are a couple typos in the figures, which i have recently asked to be updated. there are three places where it says 0x0E, where it should say 0x0F (Figures 1, 2 and 3)

    I will work on getting a flow chart or other simplified process diagram which may help as well. Will need a day or so to get that together for you.

    BR -
    Josh
  • Josh,

    Were you able to put this together for me?

    Also, the customer has one more concern regarding parity. See below:

    "Assume we set the device to automatically constant sample. The temperature reading is over two bytes, address 0 and address 1.

    Assume I’m now reading with single I2C access both bytes, or for that matter all the first 16 bytes. My concern is that while the device sends me the data for address 0 in parallel it (by coincidence) finishes a new reading, and when it start send me the data for address 1 it comes from the new reading. Does the device have protections in place to deal with this?

    One way to solve this is that when I2C read is started the device latch all the value of current reading (temp, humidity etc) so even if the I2C is slow and new reading is finished it is ignored for this I2C access and the data send over the I2C from the device is the latch data and not the real time data, and so Q4 is to verify if the chip have any such or similar mechanism to make sure reading over the I2C have some “data integrity protection” or can it be that I get data of mix reading such as address 0 from prior sampling and address 1 from the new sampling."
  • Carolus -
    sorry for the delay - I was travelling last week - but i did get some answers to the other questions while i was onsite with our validation engineer. The software reset is same as a POR. I cannot see it (bit 7 in register 0x0E) staying high on my logic analyzer or the GUI. I can see that it is written and then cleared when I read it back. Then i can reconfigure the device, write a 1 in bit 0 of register 0x0F and resume.

    As far as reading two devices on an I2C bus, each will have its own I2C address and the protocol will behave as per the I2C spec. reads and writes are done individually, the master always requests data, the slave can never send data unsolicited in I2C ...so I am not sure I quite understand how the situation would even be possible as you say the customer is describing, that is just not the way I2C works - it (an I2C slave) is not allowed to stream data like a UART can do.\

    WRT to the flow:
    the diagram in the guide is accurate except for the typos in the notes where it calls out 0x0E register vs. 0x0F to start the measurement.

    Basic flow is set sampling rate and resolution, then start the measurement. DRDY/INT will raise or lower (based on the active configuration) as the conversion is completed, which would signal the I2C Master (MCU) to go to get the values from the I2C Slave (HDC2010, in this case)

    Hope that clears it up and again, sorry for the delay.