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: Erroneous temperature data and HH_STATUS=1

Part Number: HDC2010
Other Parts Discussed in Thread: CC2640

Hello, we have the following issue when doing a measurement using HDC2010. The sequence is as follows:

1) Power on the sensor, wait 4.5 ms. (the datasheet says the sensor should be ready in at most 3 ms) The supply stabilizes at 2.95V immediately (like, within 0.1ms) and seems very clean when sampled on the scope. 

2) Issue a MEAS_TRIG command.

3) Poll the DRDY_STATUS bit to see if the measurement is complete. ( The polling takes around 1ms each time, and usually the sensor reports data ready on the second time we poll it. )

4) When DRDY_STATUS==1, read out temperature and humidity.

5) Power down the sensor.

What we occasionally see is captured above: 

After powering up and starting the measurement, the sensor reports status 0x90 (DRDY_STATUS==1 | HHSTATUS==1) the first time we read out register 0x04. When we proceed to read out the temperature and humidity data, the temperature is typically a few degrees higher compared to earlier (successful) measurements, and the humidity value is always saturated to 0xFFFE. 

Any insight you may have as to what causes this critical issue, and what can be done to remove it, is highly appreciated.

  • I have found that adding a soft reset and a 1msec wait before issuing the MEAS_TRIG command seems to make the problem disappear (or at least harder to reproduce).

    But while investigating this, I came across this reply to a similar question: https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/823877/hdc2010-erroneous-readings/3070481#3070481 

    This is deeply concerning. To me, it seems like we need to do two soft resets to better circumvent this issue? And even then, there seems to be no indication that the sensor delivers reliable data across the specified temperature and voltage range? The thread in question is two years old, but still there are no erratas or similar to be found about this. Please let me know if I have missed something. Unreliable sensor data is evidently a major blocker for us.

  • Hi Paal,

    Can you send us all the register values after power up? 

    Regards,
    Pavani

  • I dumped the register values after power-up, just before setting MEAS_TRIG. I captured the values for the normal case and the case where we see the above-mentioned issue:

    Address When OK When there is an error
    0x00 0x00 0x1C
    0x01 0x00 0x69
    0x02 0x00 0xFE
    0x03 0x00 0xFF
    0x04 0x00 0x10
    0x05 0x00 0x69
    0x06 0x00 0xFF
    0x07 0x00 0x00
    0x08 0x00 0x00
    0x09 0x00 0x00
    0x0A 0x00 0x00
    0x0B 0xFF 0xFF
    0x0C 0x00 0x00
    0x0D 0xFF 0xFF
    0x0E 0x00 0x00
    0x0F 0x00 0xF6

    Clearly, the register values can not be relied on to be properly reset by the power-up, which explains why the soft reset helps. Can anyone from the TI sensor team please comment whether this is sufficient, though? The above mentioned post is quite worrisome, seeing that it suggests that two resets absolutely are needed in some cases.

  • Hi Paal,

    Register 0x0F cannot be configured to 0xF6. The settings are not retained over the power cycle. 

    The NA configuration of this register occurs when the operating voltage is above 2.3VDC and there are two ways around this register corruption in your system. 

    1. If possible, change the input voltage to the HDC2010 to 1.8VDC. You could use voltage divider on the GPIO or change the CC2640 based system to run from 1.8VDC using the external regulator mode available on that device, so the GPIO would then be at 1.8VDC.  

    2. If #1 is not possible, then you can, after power up and before configuring the device further (if deviating from default) or sending a 'start conversion' (i.e. 0x01 to 0x0F) - send this custom command string to the HDC2010 device and this problem will be eliminated. The implication of the usage of this is that the idle current will be ~200uA (vs. 80uA)  after 0x04 is written to 0x45. Since you turning off the part after you measure, this should not impact you greatly, as the sequence is short and the measurements are made and returned quickly, but will be some extra draw you need to know about and perhaps account for in your system.  You could also run this sequence as a trap, after reading non-zero value in 0x0F after power up, so as to not always do this, but only when it occurs. 

    Command Description Register Address R/W Data

    Custom Mode Entry

    (3 writes to I2C address)

    0xF1 W -
    0xE7 W -
    0xFF W -
    Custom Command 0x45 W 0x04
    Custom Mode Exit 0xE1 W -
    Software Reset 0x0E W 0x80

    Custom Mode Entry

    (3 writes to I2C address)

    0xF1 W -
    0xE7 W -
    0xFF W -
    Custom Command 0x45 W 0x04
    Custom Mode Exit 0xE1 W -

    Regards,
    Pavani Tenneti

  • Hi Pavani,

    This was a bit confusing. The datasheet does not mention any limitation related to 2.3V, but rather allows for a supply from 1.62V to 3.6V. We run from a 3V coin cell, so that fits well. There is no way for us to switch to 1.8V in this system, so we have to make a reliable solution otherwise.

    What seems to work for us is:

    • Turn on power supply
    • Wait > 3ms
    • Send SOFT_RES
    • Wait 1ms
    • Send MEAS_TRIG
    • Wait 3ms
    • Read temp + humidity
    • Turn off power supply

    Are you saying that the soft reset may not be sufficient to overcome the bad chip state and prevent the error in all cases? The control scheme you mention is quite a bit more complex, and with bit-banged I2C it will burn a lot more energy from the battery each time, so we'd rather want to avoid it. 

    Will register 0x0F always have the value 0xF6 when the chip is in this state?

    Also, this is a pretty serious issue that I'm sure must be relevant to many customers (from what you say, all customers operating above 2.3V). Can you provide an errata describing this issue in more detail?

    Regards,

    Pål Øyvind

  • Hello Paal,

    We would be willing to debug this further, but would need to consider application level details and could pursue device-level bench testing to ensure we understand the root cause of this behavior. Unfortunately, we cannot guarantee that the behavior observed would be corrected with the soft resets. Could you please send me a PM with your email address so that we could setup a call to discuss in more detail?

    Regards,
    Pavani Tenneti

  • Thanks Pavani, I will PM you so we can setup a call.