I2C - Send "Measurement Request" to HIH6130 IC

MattKefford · ‎2021-08-04

Hi, I seem to be having difficulty with what should be a simple I2C task. I want to send the Measurement Request to the Honeywell sensor so it will take a temperature and humidity reading, which requires the following format from their datasheet:

I have been using the following for my test code:

I have the array ready to receive the 4 bytes when I read data. I pass it in to the transmit function as a dummy parameter but set the length as 0 since we are not required to send any data for the measurement request.

Here is what is produced on the I2C lines. Unfortunately the place I work at only has one probe currently so I had to take the SCL and SDA readings separately:

I combined the scope traces into a diagram. It all looks good until after the ACK bit when an extra bit is present and has just a spike at the beginning of the bit:

In terms of what is received when debugging the code, I get this:

This actually looks like the correct format as the first two bits are status bits and the last two bits are to be ignored ("don't care" bits) so it looks like a valid packet that contains the maximum sensor values for temperature and humidity (100% and 125ºC).

If I read the data a second time I see the status bits go from 00 to 01 which indicates stale data:

So it seems the IC's state machine is working and it is aware it is being read from, but the measurement request packet is just not valid and doesn't trigger the sensor to take a reading?

In terms of the electronics here is the schematic and the I2C lines have 2.2k pull-ups, which is the same as the Sparkfun breakout board:

The only difference with our circuit is that we also have an EEPROM on the I2C bus with an address of 0x50 so it shouldn't interfere.

I've tried the I2C at both 100 and 400 kHz and I have tried various settings for the Rise Time, Fall Time and Digital Filter settings:

Is anybody able to help because I am at a complete loss with this. I have contacted Honeywell's technical support and had no response from them so this is my only hope really.

Thanks!

Matt

MattKefford · ‎2021-08-21

This is now solved, it was a hardware issue!

The logic part of the IC was fine but the sensor was damaged so unable to take a measurement and so just returned 0b11111111111111 for each value.

After desoldering our on-board IC and wiring up a Sparkfun breakout board I managed to get sensible readings with my test code. We are suspecting IPA or flux.

For anybody else interfacing with this sensor (or one similar) the code was super simple in the end.

For the Measurement Request I did something like:

HAL_I2C_Master_Transmit_IT(&hi2c2, (0x27 << 1), NULL, 0);

The glitch remained there but causes no issues. It is as TDK pointed out, it occurs between rising SCL edges so has no effect.

And for reading the data from the IC I added a static uint8_t sensorDataBuff[4] = {0}; up at the module scope level and called:

HAL_I2C_Master_Receive_IT(&hi2c2, (0x27 << 1), sensorDataBuff, sizeof(sensorDataBuff));

I then just added the HAL_I2C_MasterRxCpltCallback() to my module and parsed the bytes that were put into sensorDataBuff.

View solution in original post

TDK · ‎2021-08-04

The "glitch" in SDA is on the ACK bit and is likely due to the slave giving up control of the pin and the master taking over. It happens when SCL is low and can be ignored.

Not sure why it's not returning good values, code seems fine, signals seem fine.

If you feel a post has answered your question, please click "Accept as Solution".

MattKefford · ‎2021-08-06

Hey thanks for your input 🙂 I think you're right about the glitches. On the same I2C bus I have an EEPROM which has the same spikes but works just fine.

I'm totally baffled by the HIH6130. I have tried other addresses of 0x26 and 0x28 which both return a NACK. 0x27 returns an ACK so clearly it is happy with the address but still won't trigger a measurement to start for some reason.

Honeywell technical support have seen my email now so hopefully they can give some advice. I will update here if I find a solution.

MattKefford · ‎2021-08-21