trouble with BBB and I2C temperature sensor (HIH 6130)

Hi everyone, I just got my BBB and I wanted to get temp/humidity so I got a HIH6130. I have a good amount of experience with OOP and HDLs, so I can read code and I also understand the low level stuff working directly with bits, however I have zero experience with I2C and I have no idea how to use it.

I read a lot of other simple I2C programs, one example being http://beagleboard.org/Support/BoneScript/demo_bmp085/
I modified the code to match the address of the HIH6130 and the two functions given by the kernel driver (https://www.kernel.org/doc/Documentation/hwmon/hih6130)

`
var b = require(‘bonescript’);
var iic = ‘/sys/class/i2c-adapter/i2c-1/’;

//Sensor Locations on the BeagleBone Black
var temperature = ‘/sys/bus/i2c/drivers/hih6130/1-0027/temp1_input’;
var humidity = ‘/sys/bus/i2c/drivers/hih6130/1-0027/humidity1_input’;

// We will initialize the driver for the BMP085 sensor located at I2C location 0x77
b.writeTextFile(iic + ‘new_device’, ‘hih6130 0x27’);

// Opens,reads, and prints humidity and temperature
b.readTextFile(humidity, printHumidity);
b.readTextFile(temperature, printTemperature);

// Prints humidity
function printHumidity(x) {
console.log("humidity: “, x.data/100 + " %”);
}

// Prints Temperature
function printTemperature(x) {
// ‘\xB0’ is the degree symbol in hexademical
console.log("Temperature: “, x.data/10 + ‘\xB0’ + " Celcius”);
x.data /= 10;
x.data *= 1.8;
x.data += 32;
console.log("or: “, x.data + ‘\xB0’ + " Fahrenheit”);
}
`

I didn’t really care about the math behind the information so I left it alone. When the above code is run I get NaN for everything. I’m assuming because it is literally trying to read the “temp1_input” and just dump that to the screen. However…

`
root@beaglebone:/sys/class/i2c-adapter/i2c-1/1-0027# cat temp1_input
cat: temp1_input: Invalid argument

`

nothing is there.

According to the datasheet (http://www.phanderson.com/arduino/I2CCommunications.pdf) It says the device is sleeping and needs to be sent a “measurement request” command in the form of [6bit address][0].
My main problem is I’m not sure how to send data directly to the bus. I was thinking about using the i2cset command, but that doesn’t seem right as it sets a specific address of memory on a specific device. According to the datasheet I’m not trying to send it data other then the address + a ‘0’ but the other i2c tools don’t seem to be any more help.

Last, here’s an i2c dump of the device.

`
root@beaglebone:/sys/class/i2c-adapter/i2c-1# i2cdump 1 0x27
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x27, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e ^^^^^^^^^^^^^^^^
10: 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e ^^^^^^^^^^^^^^^^
20: 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 5e 17 57 57 57 57 ^^^^^^^^^^^?WWWW
30: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
40: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
50: 57 57 57 57 57 57 57 17 57 57 57 57 57 57 57 57 WWWWWWW?WWWWWWWW
60: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
70: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
80: 57 57 57 17 57 57 57 57 57 57 57 57 57 57 57 57 WWW?WWWWWWWWWWWW
90: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
a0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 17 WWWWWWWWWWWWWWW?
b0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
c0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
d0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
e0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW
f0: 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 WWWWWWWWWWWWWWWW

`

I wouldn’t call it “garbage data” per se, however it isn’t very useful.

If anyone has experience with the HIH6130 or really any pointers on how to send specific bytes directly to the I2C bus would be great.

Thanks a lot!

You may be in a bit of a bind. The Linux kernel drivers for I2C don’t really give you a function for this that I have seen. Specifically to write the “WRITE” address of the device to the bus and then immediately terminate the transaction. You could see if it will respond with something interesting if you try to write a dummy value to it first instead of just the device address. It may ignore the other data bits after it’s “WRITE” address and just wait patiently for the “STOP” condition to occur. If so then it should wake up and perform a measurement. Kind of ugly but it might work. If it freaks out because another byte follows the address after it ACKs then you may be a bit stuck without getting your feet wet in writing some more capable I2C drivers.

I need to watch the output of i2cdetect sometime and see what it does and how it does it. This is almost the mirror image of the type of ‘ping’ it’s doing using the write address instead of the read address. I always detected devices on micro-controllers by iterating through the “READ” address space, “START” the bus, write the “READ” address to the bus and detecting the ACK then “STOP”, increment address and repeat. In micro-controller world it would be easy enough to do that for a write as well but it’s more complicated in Linux Kernel land.

Afraid I don’t bonescript though, so I don’t know much about I2C functions available for that or how to code them.

I imagine on the basis of the data sheet that the result of i2cdump is just gibberish. The normal sequence to get register data (which this device doesn’t appear to even have) would be:

START
Write the WRITE address to bus, followed by register address as data.
REPEATED START or perhaps STOP | START
Write the READ address to the bus and data bytes that follow until NACK.
STOP

Looking at the datasheet the best you might be getting is the first byte of humidity data and status bits repeated. Usually a total failure to respond at all is FF so I think it’s at least trying to speak with you.

Ok. So what I’m gathering is that the Linux Kernel drivers don’t allow for direct manipulation of the I2C data bus.
So can I simulate my own? Use two of the GPIOs and have one be a clock and one be a data line?

Is that feasible?
Can a GPIO operate at 100kHz?
If not can I2C devices operate at clocks of lower frequencies? (would 50kHz work? 10kHz?)
Would the I2C device care? Or would it just be happy receiving a clock and spitting out data?

I already know the device’s address, and that cannot change so that would just be a static 7 bits I’m sending over the “data” line add on my 0 for “make measurement” then just listen for one bit at each clock edge, when I get 8 bits, send a ACK and continue.

Shouldn’t that work just fine outside of the real I2C bus?

I normally use the i2c without any problem…

You can play with the onboard i2c0, enable it and just do Or connect something on the other bus and do the same… The code I use i the following

When I was cut/pasting commands and making changes to adjust the power LED, I fumbled a few times and ran command like
`
i2cset -f -y 0 0x24 0x0B

`

Where I left off the DATA to be sent and just had the register address. i2cset didn’t complain and was perfectly happy to try to write without sending data[and a quick look at the underlying code, http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L1956 it doesn’t seem to care at all if the value is null.

As such, I’d say give a try writing to register 0 with no data, ie

i2cset -f -y 1 0x27 0x00

Don’t forget to include the -f! i2cset is configured not to write to any i2c addresses if there is another driver configured for that device!

Note: this command does not always give the correct data if your running it against a device where linux already has a driver loaded. Depending on the device, sometimes it looked like it work but I got the wrong data, and sometimes it fails outright. I had to add the force flag in order to get data which looks right, for example to dump the board id from the eeprom:
`
root@ubuntu-armhf:/home/ubuntu# i2cdump -y 0 0x50
No size specified (using byte-data access)
Error: Could not set address to 0x50: Device or resource busy
root@ubuntu-armhf:/home/ubuntu# i2cdump -f -y 0 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
20: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
40: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
60: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
80: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
a0: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
c0: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
e0: 55 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U…
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …

`

The Linux generic /dev/i2c-X device driver can do everything you need to do except send just the address and no other data as far as I can tell. All the functions that I have worked with appear to expect data to be sent to a device you are going to write to. I think the command line suggestions by garyamort are not going to send exactly the wake-up that the sensor documents and would instead send:

(Note: 4E is the actual write address that is sent to the bus after the driver shifts 0x27 left one bit and leaves the trailing bit at 0 for a write)
START | 0x4E | 0x00 | STOP

where you want:

START | 0x4E | STOP

You might see if you can write a program that just uses the Linux device file that will work. See this page:
http://elinux.org/Interfacing_with_I2C_Devices

So try the write example but change the number of bytes to write to zero and see if that works for you then when you turn around and read. I would also test and see if you send a dummy data byte after the write address and have it still work. It may not be that picky.

Yes, you can always bit-bang an I2C bus and there is code out there in C/C++ to do that you could adapt. If you don’t have access to a logic analyzer you’re probably looking at a lot of work to get there and debug. Hopefully something above works for you and you don’t have to reinvent the wheel to wake the silly thing up.

There are a few libraries showing up now that use memory mapped access to GPIO that can reach far beyond 100KHz on GPIO. Even a decently well implemented SYSFS interface to GPIO can likely get close to 100KHz doing some real work in between. I2C can operate at any frequency at or below the maximum speed of the slowest device on the bus. So if your device can operate at 100KHz it can most likely also operate at 10KHz or 1KHz. Some devices do have a floor so check the datasheet carefully.

I just came home from my parents place in Ohio, and of course I left the Beagle Bone there, so I can’t test out anything right now.
But, I do know that I already did try an i2cset command using 0x4E (0100 1110) as the address with no data and I got an invalid address error. Which I ignored because I assumed the linux kernel was expecting some sort of reply from that address when, in-fact, it would have just woken up the device on 0x27 (assuming it worked).

I did an i2cdump on 0x27 before and after the i2cset 0x4E and the numbers were different. However the output was exactly like the output I showed in the first post.

One last piece of information that I can add is this. I also assumed the i2cdump data was valid. Taking the first 4 bytes and applying the logic in the data sheet. For example the first 4 bytes in my first post is 5E 5E 5E 5E. The datasheet says the first 2 bits are status, and the last 2 bits are don’t care’s. Some quick math says the Humidity is 0x1E5E and the Temp is 0x1797. Converting to decimal and doing the math in the datasheet yields a measurement of 47.4% humidity and 20.89 degrees C. Those seem to be fairly valid results, however when I did the same thing again a few minutes later I got results that were closer to 25 degrees C. I had a thermometer sitting next to me, the first measurement was almost a full degree off, which I thought was good enough, the ambient temp didn’t change between the measurements, making the 2nd measurement WAY off.

Also I’m not sure of the validity of the data since in the i2cdump since it is repeated so much.
Last point of concern is that to read the device I need to append a 1 to the device address.
So, 0x27 = 0010 0111 (device), 0x4E = 0100 1110 (bit shift left one, device wake up, and take measurement), 0x4F = 0100 1111 (read bit)
Is the linux kernel doing that last bit on it’s own? Or is that the problem here, the i2cdump command isn’t sending out the proper “Read flag” or “0x4F address” and thus I’m not able to get the 4 bytes because the device isn’t actually communicating?

``Some new developments:

I got the source code for the linux driver for the HIH6130

`
/* Honeywell HIH-6130/HIH-6131 humidity and temperature sensor driver

Find the sensor address and do a simple i2cget

i2get “bus number” “device address” “register address”

`
root@beaglebone:/sys/class/i2c-adapter/i2c-1# i2cget -y 1 0x27 0
0x60
root@beaglebone:/sys/class/i2c-adapter/i2c-1# i2cdump -y 1 0x27
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 10: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
20: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 30: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
40: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 50: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
60: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 70: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
80: 60 60 60 20 60 60 60 60 60 60 60 60 60 60 60 60 ``` ````````````
90: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 a0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
b0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 c0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
d0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 e0: 60 60 20 60 60 60 60 60 60 60 60 60 60 60 60 60 `` ````````````` f0: 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
root@beaglebone:/sys/class/i2c-adapter/i2c-1#

`

I don’t think the device has registers, I could be wrong. Either way the above information isn’t helpful.

This an arduino code I’ve found
Reading the sensor doc I think you just have to “call” the sensor whitout the register, and after a small delay read the received data. I don’t know how to replicate this behaviur in i2cget…

Well, I started thinking the module was bad. (namely because the driver made for this exact device isn’t working)
Last ditch effort I hooked it up to an arduino and copied the code on sparkfun’s website.
Turns out it works, the humidity is off by ~10% (not usable with that much error) but the temperature was spot on.

So now I’m not sure what to do, I really don’t want to design my own data bus, it’s not in the scope of my project.

Last thoughts from anyone?
Different temperature sensor (something someone has experience with? I would like something more accurate then +/- 2C, which is why I opted away from an analog TMP36)
Or other ideas?

Well, I started thinking the module was bad. (namely because
the driver made for this exact device isn't working)
Last ditch effort I hooked it up to an arduino and copied the
code on sparkfun's website.
Turns out it works, the humidity is off by ~10% (not usable
with that much error) but the temperature was spot on.

What are you using as a reference to determine it is 10% off?
Humidity is often not completely uniform.

I am using a commercial temp/RH monitor. It’s a simple little device, nothing special.
I ran the test again and it was closer to 5% different. So maybe the RH is accurate too and my standalone is off.

However, I was beginning to suspect the sensor was defective because the drivers made for it don’t do anything.
I don’t want to make my own clock and data signals with my own driver, and I don’t want to plug an arduino into my BBB.

Your problem might actually be in the ti driver. As near as I can tell, this will call i2c_master_send in i2c-core.c
https://github.com/torvalds/linux/blob/master/drivers/i2c/i2c-core.c#L1775

There it will setup:


msg.addr = client->addr;
msg.flags = client->flags & I2C_M_TEN;
msg.len = count;
msg.buf = (char *)buf;

Where buf is

Sorry, posted too soon.

Where buf is a pointer to a 4 byte charector string[tmp from the original driver, which is an uninitialized 4 byte charector string, so it could contain anything!]
And count is 0 [length 0]

This goes to i2c_transfer in the same file:

As a followup, because this seems to be a TI driver issue and not Beagle Bone Black specific, I did a quick search of the TI forum and ran across this post:
http://e2e.ti.com/support/embedded/linux/f/354/t/153514.aspx

Which deals with a similar issue. It seems that in order to write just the address to the i2c transmission with no data you need to use the i2c_smbus_access() function.

While this feels like a bug in the TI i2c protocol driver since it should support the SAME command usage as the basic i2c protocol drivers, rather than waiting for TI to fix it a possible workaround would be to rewrite your driver as follows:
In the function hih6130_update_measurements. Based on https://www.kernel.org/doc/Documentation/i2c/dev-interface I think what you would need to do is:

  1. make sure to load the i2c-dev driver. I think modprobe i2c-dev should do it. Then check the /sys/class/i2c-dev/ director to see what adapter numbers are assigned. Finally, in the driver, at the top of the file make sure to add:

#include <linux/i2c-dev.h>

replace

/* write to slave address, no data, to request a measurement */ ret = i2c_master_send(client, tmp, 0); if (ret < 0) goto out;

with
`
/* write to slave address, no data, to request a measurement */

/* HACK: open the i2c-dev file for the i2c device /
int i2cs_smbus_file;
int adapter_nr = 2; /
use numbers determined from checking the /sys/class/i2c-dev folder */
char i2cs_smbus_file[20];

snprintf(i2cs_smbus_file, 19, “/dev/i2c-%d”, adapter_nr);
i2c_smbus_fd = open(i2cs_smbus_file, O_RDWR);
if (i2c_smbus_fd < 0) {
/* ERROR HANDLING; you can check errno to see what went wrong. Probably should return a more intelligent error code here */
return i2c_smbus_fd;
}

// setup the smData structure with a length of 0 to indicate no data to be cent
union i2c_smbus_data smData;
smData.length = 0;

// create some dummy data by using the sensors address
__u8 i2c_smbus_data = client->addr;

// Silly call to write to the file using a broken stream of data
ret = i2c_smbus_access(i2c_smbus_fd, I2C_SMBUS_WRITE, i2c_smbus_data, I2C_SMBUS_I2C_BLOCK_BROKEN, &i2c_smbus_data);
if (ret < 0)
goto out;

// cleanup our file handle
int closeFileReturn = 0;
closeFileReturn = close(i2c_smbus_fd);

`


There are a couple of other ways of doing the above depending on how much deeper you want to go.

I'm not sure about the placement of the file close function call, or if it is even really needed.  Because file operations slow things down, ideally the i2c_smbus_fd handle should really be placed in the driver initialization and stored either globally or in the device structure - that way it can be opened once and reused, rather than opening and closing it every time you want to take a reading.

Of course, I'm not really sure about the entire code to begin with.  I'll pick through my various modules and see if I have an i2c device that works in this manner[ie send it the address with no data, then read the return value] and if so I can test it out...or if you want to setup your device with remote SSH access I'd be happy to hack the driver and compile it there and see if I can get it to work.