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.
Part Number: HDC1080
I'm trying to understand whether I'm implementing this correctly in Verilog. Should I be expecting a STOP after the ACK when I transmit the trigger message. I get a STOP but maybe I shouldn't because it's not shown on the datasheet Figure 12. I'm configured for temperature and humidity in sequence. In addition, when I transmit a read message to obtain the measurements, I seem to get the first byte and it appears to be real. The first byte is ACK'ed. However, the remaining 3 bytes come back as 0xFF followed by NACKs. (the last byte should get a NACK - so that's ok).
Any ideas? Carmine Iascone, are you out there?
here is what it should look like on I2C bus
Trigger Measurement (yes the Master should stop at end - (ie. where the red dot is))
Read Temp and point to next register
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 Josh Wyatt:
Thanks Josh. I'm curious, though, whether you've had problems reading temperature and humidity measurements when configured for the acquisition mode where Temperature and Humidity are acquired in sequence, Temperature first. One read transaction returns 4 bytes - two bytes for temperature and two for humidity.
I get the temperature MSB then and ACK. But then I get 0xFF followed by NACKs for the remaining 3 bytes.
Is there some delay I need to implement between bytes?
In reply to Craig Meyers:
do you have an LSA or 'scope capture of what you are sending out and RXing? That would probably help.
This is the best I can do at the moment. When I manually perform a read transaction, works fine:
This is what my Verilog is doing:
Please confirm - what i see is here in this last capture is an attempt to read four registers at once, and it would be helpful to know that you sent a pointer byte beforehand. (please refer to the captures i put in the first response and to section 126.96.36.199 in the datasheet (page 11) http://www.ti.com/lit/ds/symlink/hdc1080.pdf
It should be three separate transactions and with a waiting time for the resolution you chose in the first place by writing register 0x02. Also, if the part is NACK'ing you, most likely not enough time is elapsed (see Figure 13, page 12 in datasheet as example)
I was modeling the read transaction according to Figure 14 in the datasheet. One transaction sending the pointer byte first (h81). I'll have to go back and re-review your original post.
I tried a single read transaction. Reading temperature. I trigger first h80/h00. Wait about 32 ms. Then read temperature (h81). After I get temperature MSB (h66), I should get an ACK rather than a NACK. Maybe the temperature LSB is actually hFF. But that seems unlikely.
What am I missing?
Looks like the master is taking control/not taking control (depending on how you look at it) of the SDA line perhaps at the end of the first byte of the response and leaves it high for the duration. Is that the case? this would result in the NACK you see at the end of the first byte and the 0xFF you see on the second byte of what should be the response from the part.
Yes. It would seem that my Verilog is holding the data line high when it shouldn't be. I'm not immediately seeing the problem. I'll have to play around to see if I can fix it.
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.