Part Number: HDC1080
One of our customers is evaluating HDC1080 on their own board for their next products.
In the evaluation, when they read temperature and humidity data repeatedly through I2C from HDC1080, the both data become 0xFFh rarely.
I2C clock frequency is 400kHz.
Could you tell me what could be the cause?
Your reply would be much appreciated.
Do you have a logic analyzer capture of the I2C read that you can share?
Additionally, what are the set conversion times?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Nicole Khoury:
Thank you very much for your reply.
They are trying to get total I2C data logic capture or oscilloscope waveform of the 0xFFh reading case.
I will send you the data as soon as I get it
Also I confirmed they set configuration register to 0x00h.
So I think each parameter setting should be as the follows.
// Humidity MeasurementResolution = 14bit
// Temperature MeasurementResolution = 14bit
// Mode of acquis = Temperature and Humidityare acquired insequence, Temperature first.
// Heater = Heater Disabled
// Software reset = Normal Operation
Thank you again and best regards,
In reply to Kazuya Nakai59:
The customer took some waveforms when temp and humidity data was 0xFFh as the attached.
As a n additional information, one 0.1uF ceramic capacitance is placed jusy nearby HDC1080.
Could you please check their waveforms and give me your comment?
Thank you and best regards,
Thank you for the data.
I believe the I2C stop condition is being violated, which can be seen in your 6th waveform image. In this capture the SCL line stays low while the SDA line transitions from low to high. To signal a stop condition SCL should be high while SDA is transitioning.
I understood well what you said.
Could I ask you a few additional questions as the follows?
Q1. Is the stop condition needed to insert to the end of Frame 2 (Pointer register byte write timing)
because we can't see the stop condition at the timing in figure 12 on page 12 of the device dtasheet?
Q2. The customer is using figure 12 and figure 14 together to trigger measurement and measurement data reading as the follow.
Frame 1 + Frame 2 (Figure 12) sending -> Wait 20ms for Temp/Humid measurement -> Frame 3 ~ Frame7 (Figure 14) sending using repeated start.
Is this sequence wrong to trigger measurement and read the measument data?
A1. You're correct that figure 12 does not have a stop condition pictured, but a stop is usually issued after the measurement trigger command. A stop, or at least releasing the SCL line, is preferred to holding SCL low.
A2. The sequence seems correct, but SCL is being held low and a stop would be preferred.
Thank you for your reply.
I asked them to try to change SCL lever to high and to check whether 0xFFh output phenomenon is solved or not.
At this moment, they have a question as the follow. Could you please give me your reply?
Q. Has TI ever seen this 0xFFh output phenomenon?
Here was a similarly presenting issue regarding humidity readings with the HCD1080: https://e2e.ti.com/support/sensors/f/1023/t/621625?tisearch=e2e-sitesearch&keymatch=HDC1080
In this scenario, increasing the conversion time to 100 ms seems to have resolved the problem.
Thank you for the information.
I will ask them to try to read the temp and humid data after 40ms or longer wait time.
But HDC1080 datasheet says like the follow on page 12 of the device datasheet.
4. Read the output data:Retrieve the completed measurement result from register address 0x00 or 0x01, as appropriate, as shown inFigure 11. A read operation will return a NACK if the measurement result is not yet available, as shown inFigure 13 on page .
According to their waveform, The acknowledge of Frame 3 is low and it means read data is active.
Is my understanding wrong?
Could you please give me your comment or advice?
Thank you for your strong support.
The customer read Temp/Humid data with 40ms wait time.
But 0xFFh was still read.
Do you have any idea to solve this 0xFFh reading problem?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.