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.

HDC1000 EVM uC Source Code

Other Parts Discussed in Thread: HDC1000

I am working on a design the uses and MSP430 with the HDC1000, and having some example source code would certainly speed up development time. Can TI provide us with the source code for the HDC1000EVM? This tool's source code should have exactly what I'm looking for.

This question was asked in another thread last October:

"e2e.ti.com/.../1471930"

In that thread, a TI employee claimed it would possibly be made available soon, but that was 6 months ago, and it's not currently available still. Some assistance would be greatly appreciated.

  • As answered in the other thread, we are working to format the coe in the right way to issue on the ti.com
    The forecast is to have the code available in few weeks from now.

    Regards
    Massimo
  • Thanks. It's been about 6 months since the original person asked for it, and so I hope it will actually be delivered soon.

    While I would still to see that code, my project's development couldn't wait, and within two days, I was able to get code working that allows me to read and write to the sensor. I have verified read/writes of the Configuration Register, and reads of the manufacture ID register, but for some reason I can't get a good read of the temperature or humidity measurement registers.

    Currently the board I have has the DRDY pin tied to an input on the MSP430, but a pull-up resistor wasn't included on this line, and so I have reconfigured the input as an output that holds the line low (the design specification recommended the line be tied to GND or NC when not used)

    Each time, I send the Configuration Register (0x02) the String 0x1000 or 0x0000, then I delay for 7 to 15ms, and then I attempt to read the temperature or humidity register, but I always receive a NACK indicating data isn't ready.
    The difference in the configuration strings was just be to configure the sensor to do both temperature and humidity measurements or just one of the two.
    I have tried waiting longer periods of time as well, and it always NACKs upon attempting to read.

    I will be adding the pull-up to the DRDY pin in case that's somehow causing the problem, but until I get to that, could someone provide some insight as to what may be causing this situation?
  • DRDY pin is a open drain output. For this reason we suggested to connect to GND when is not used.
    Regarding the SW it is in high priority and I really hope to issue on ti.com examples of soure code as soon as possible.

    Looking at your issue:
    the correct sequence to read the output is:
    1) Write configuration register

    2) Write the pointer 0x00 -- To start the conversion

    3) wait 15ms

    4) Read 4 bytes outputs --> ATTENTION: without write again the pointer otherwise a new conversion is triggered

    It should fix your problem

    Regards
    Massimo
  • Thanks, I was doing that stuff, but it turns out I was not sending a stop condition after writing the pointer to start the conversion and my delay needed to be 20ms.

    The frames in Figure 12 on Page 12 of the sensor datasheet do not specify a stop condition should be sent after writing the temperature measurement pointer to trigger a measurement. From my experience, it won't work without it. This appears to be an error in the datasheet.

  • Increasing the wait time from 15ms to 20ms helps. T
    The conversion time for the humidity is 6.6ms and for the temperature is 6.35ms quite close to the suggested 15ms.

    I'm double checking the Stop condition after the writing operation.

    Massimo
  • I just checked and the "Stop" after the writing operation is not mandatory.
    If the Stop is not asserted the I2C line is locked but after 20ms (time needed to complete the conversion plus some margin) the data is available.

    I'm going also to repeat the test on different board with different pull up resistors value just to exclude I2C miscommunication on the line.

    Regards
    Massimo
  • Thanks for the reply.

    Measurement Delay Timing:

    That's interesting. I did initially assume 15 ms should be more than enough time based on the same datasheet information you referenced, but testing indicated more time was required. I'm not certain of the minimum time I can set for the delay and still get a data (when 15 ms wasn't enough, I just jumped up to 20 ms), but I know 20ms works. I use a timer interrupt for delays, and while I've verified the timing is correct for larger time frames (250ms timing was verified on an oscilloscope), it's possible a smaller time frame is less accurate. While I doubt this is an issue, I'll eventually evaluate the accuracy of shorter time frames, but I'm comfortable with the current functionality for now.

    Stop Bit Between Write and Read for Measurements:

    I'm surprised to hear your code works without a stop condition. I have tested mine several times with and without the stop condition (I just did it twice more to be sure), and it always receives a NACK when I attempt to read the measurements if I don't send a stop after writing the temperature (0x00) pointer to start the conversion cycle. In the off chance this was a timing issue, I have even tried increasing the delay to 25ms when the stop condition isn't sent, and it did not change the results.

    While I'm glad everything works, I'm curious why yours works without the Stop condition, and mine does not. Here are some things worth mentioning:

    -When I read the Manufacture ID register, I do the following:

    Write Data Pointer:

    Send: start condition, address, write bit, register pointer (0xFE)

    Read Data:

    Send: start condition, address, read bit

    Receive: two bytes (CHAR: TI, as expected)

    Send: NACK, stop condition.

    As you can see, there is no stop condition between the write and read transactions. This is contrary to what I need to do for reading measurements, and I'm wondering if this difference is related to the delay between the read and write transactions.

    *It should also be noted that if I do send a stop condition between the write and read transaction, I still successfully receive the Manufacture ID bytes.

    -The MSP430 part I'm using is the MS430G2755

    -I have another I2C sensor on the bus. It's an accelerometer, has the address 0x1E, and my code does not currently support it yet. 

    -My I2C bus uses 10k Pull-Ups, and since my original posting, one has been added to the DRDY pin.