I2C Communication, PIC 16F616 to Honeywell humiditysensor HIH6131

I'm trying to set up the sensor in by puting it in command mode. This is to enable reading humidity with alarms set up in this mode.

to start:

power on of the sensoris done first.

I2CWRITE PORTA.1, PORTC.1, $4E, $A0, [$00, $00] Noack ' starts command mode
The 4E is the address (27 plus a write bit=0) The A0 is the command to enter command mode. The 00s are required per Honeywell . Port A.1 is SDA, PortC.1 is the CPIN.

I delay 1 ms to allow the sensor power on reset time. The message always is NACKed after the first byte (the address) If I skip the command mode for test purposes and try to enter measurment mode, the same happens, NACK of the first byte.

Does anyone know of a resolution? I need your help.

Joe Rapoza (joerap)

I don't have an answer for you Joe, but this thread has a link to I2C material that might help:
http://www.picbasic.co.uk/forum/showthread.php?t=16067

Robert

Hi Demon,

I read the material at the link and used the info to create I2C communication using SHIFTIN and SHIFTOUT. This method transmits all the required info and can be seen on the 'scope. The sensor in use, still NACKs each byte. This method allows you to ignore the NACKs but the info received is not meaningful. I'm still at a loss to communicate with the sensor. My project is not going well. Hope someonecan help.

Joe Rapoza

If the first byte is always nack'ed, then there is definetely something wrong. The first byte should always be ACKed if the slave part is functioning and the address is correct. Do you have pullups on the two I2C lines?

Also the PIC Basic Pro manual recommends not using a constant for the address byte. So either skip the address or use a byte variable.

i.e. I2CWRITE PORTA.1, PORTC.1, $4E, , [$A0, $00, $00]

Hi Tim,

I tried the variable byte for the command. ie skipping the command byte and putting it in the data fields. (I2CWRITE PORTA.1, PORTC.1, $4E, [$A0, $00, $00] )

It does transmit the $4e , the $A0 and one $00. It does however, NACK all bytes. It does not go into command mode. Only status data when trying to retrieve alarm info is returned with a 0x02 meaning it was NACKed.

Still at a loss.

Joe Rapoza

EDIT: I finally found Melanie's thread:
http://www.picbasic.co.uk/forum/showthread.php?t=587

Use variables instead of constants.


Typical start-up time is 50 ms by the way.

(sample code from PBP v2.60 manual, bottom p.96)


Referring to datasheet from here:
http://tinyurl.com/7d8jwk9

PBP manual says 4K7 pull-up resistors on both I2C lines. The datasheet says 2K2 pull-up resistors.

PBP supports 100kHz I2C devices up to 8MHz. You need DEFINE I2C_SLOW 1 to run above that.

Robert

I was worried reading this thread because I am planning to design in the HIH-6131 for a new product. So I prototyped a HIH-6130 sensor into my design and modified the I2C code. I was able to successfully address the part and get a ACK back. So I have at least verified that the part responds properly, since this is the method used to wake up the part and trigger a measurement. I did make the initial mistake of wiring pins 1 and 2 wrong, (grounding pin 1 instead of pin 2) which gave me the same symptoms you saw. I am using an MSP430 and bit-banging the I2C interface, which gives me a little bit > 100 kHZ clocking.

One thing I did notice is that the documentation implies that you can special order the part with a custom address. Maybe the HIH-6131 has a different address from the HIH-6130? I will need to look into that.

Hello Falngtrea,

I finally got to talk with the design engineer for the HIH6131. He verified that what I have done is valid. He had several suggestions for me to try. None worked and all NACKed every byte. I tried bit banging. I was able to send all bytes attempted. All were NACKed.

After a discussion, it being that I received my samples in August of 2011, it appears that I received preproduction prototypes. And it is also possible that I may have received dummy units intended for a trade show. Honeywell is sending me fresh samples to try. Hopefully, these will work.

You say that you achieved 100 kHZ clock rate. I tried bit banging and still only got 25 kHz. I doubled the processor clock rate and still only got 25kHZ clock rate. Perhaps it is a idiosyncrasy of the processor.

Were you able to get a humidity count from the sensor?

Thanks for the response. Please keep in touch. I may need your advice when I get the new samples.

Joe Rapoza

Hi Tim ,

Just to let you know that I tried another new sample and it worked fine. The first 2 may have been defective or were dummies as the design engineer suggested. ( the mix-up with trade show dummy units). I am able to enter command mode and am now debugging the rest of the program.

Don't worry about the humidity sensors. If you have problems contact Honeywell support and ask to talk with Gordon, the principal engineer for this product. Insist on a conference call. He will have the answers you need.

Joe Rapoza (joerap)

Yup, I got my samples to work fine also. In fact, I found an error in my original design that uses the HIH5031 because the values read back from the HIH6131 was so much lower than I read back from the analog part.

Hi Tim,

I noted in my last post that the new samples were working fine. That is, I was able to enter command mode with no problems.

Another situation popped up: When attempting to set an Atarm_low_on limit, It appears to write to the sensor normally. When I attempted to read back what I had written, I received a different value.

Do you have the application note, Entering and Using Command Mode on .....? If so on page 5, configuration steps. Step 8 it shows a read (read bit set) and a $5A (write) to the EEPROM location. Do you think this is proper? When I do this, I see on the 'scopeThat the address is changed ( by the processor,I think) from $4F to $4E. Do you think this should be an I2CWRITE? or a I2CREAD as it appears is suggested?

Just when I thought all was well. Nothing is easy. Let me know if you have the app note. If not I will scan and send the page to which I referred .

Thanks for your help.


Joe Rapoza

FYI my copy of the doc shows step 8 with the R/W bit set to Write (0).

It looks like they don't follow a standard EEPROM process for reading and writing.
Writing is pretty straightforward. Write the slave address, then the register address, and then the data to be written using one start/stop.
Now, a typical I2C EEPROM read function writes the starting address, then uses a restart to change the R/W bit, and then reads data. But the Honeywell part, in command mode, looks like it requires a command to be sent to set the address to be read as one I2C transaction, and then a basic read transaction without an address byte to read the register content.
So you would need to do a I2CWRITE to set the register address, and then a I2CREAD with a blank address byte to read the data. It looks like the data read back is the command/status/response byte and 16 bits of register data.