HDC2010: Randomly we read 0%rh and 0°C or 0%rh and -40°C from the HDC

Dear Loris - 

The HDC20x0 devices have a firmware behavior selectable pin named DRDY/INT. The purpose of this pin is to provide an interrupt back to an MCU with interrupt capable GPIO (to allow MCU to sleep in between sensor measurement) or polled GPIO (if MCU not sleeping) when the HDC20x0 device is placed in automatic measurement mode, after a measurement has been completed, to wake up the MCU and trigger a read of the registers 0x00 through 0x03 routine. 

If you are using DRDY/INT, you should ensure that you write register 0x07 with 0x80 and then write register 0x0E for setting the automatic mode of choice. Then it would be recommended to read register 0x04 for 0x80 (data ready) after the interrupt fires, to have a redundant check that new data is ready, before reading out temperature and humidity registers. If you did not route the DRDY/INT line due to unknown constraints, or design is using one-shot mode, I would recommend at least reading register 0x04 for a value of 0x80 before reading out temperature and humidity registers, to avoid getting values asynchronously, which in your case is giving you empty values. 

Dear Loris - 

I did this on HDC2080, but its identical to HDC2010. 

This capture of how to set it up - here I set 0x07 to 0x80, then set 0x0E to 0x56 (in your case it is longer interval), then (in this case, I read out all the registers starting with 0x04) - you don't need to do this, then I sent start conversion and then firmware waits for interrupt, then reads out 0x04 for 0x80, then reads temp and %RH registers (0x00 through 0x03)

Also here is the capture in case the images are not good. 

HDC2080_HDC2010_comparison_DRDY.logicdata

Loris - 

are you triggering on DRDY/INT or waiting time? If waiting time, you have to wait >1.3mSec before reading (for first read this is the case, because after setting up the device and issuing start conversion, the first measurement will be ready in that time) - after that, you should wait for 0x80. Best way is to trigger on DRDY/INT line, read 0x04 for 0x80, then read out 0x00 - 0x03. 

Loris - 

I see what you are saying in the capture - I would not use soft reset at all, and I am not sure what happened in between that last good read and you getting 0xA8, then reading out 0x00 0x00 in the temp & %RH registers. What I have done to avoid this altogether is to not proceed to reading 0x00-0x03 unless 0x04 is 0x80. You could also read out all the registers when you get 0xA8 like that, for further troubleshooting, if that is possible. 

Dear Loris- 

As I said, sending the reset to the part is not recommended (0x80 to 0x0E). In this case, you must have some slightly older devices (which we fixed about a year ago) which had an issue where above 2.3VDC, the devices had a possibility to have register corruption.  Please use this firmware workaround when you see anything but 0x00 in register 0x0F. 

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1008725/hdc2080-faulty-0x0f-register-initialization-with-2-3v-custom-command-sequence?tisearch=e2e-sitesearch&keymatch=HDC2080%2520register# 

Dear Loris - 

the only slightly negative here is that after running the workaround, as long as power is applied and software reset is not applied, the part will draw 200uA constantly, as what the workaround does is turn on sub regulator in the device, reset the part in known good state, then turn the sub regulator back on, to ensure the issue does not occur. 

Dear Loris - 

This is the workaround with those vintage parts. The only thing you could do is reset the device with 0x80 to register 0x0E, then the part will go into shutdown normally, but then you run into the possibility of this occurring again. The only other thing I can think to do here is to read the registers (0x04 to 0x0F) periodically and only run the workaround when those are not default values.