Hi,
Problem reading from GPIO/AIO when any device is connected on I2C
Hi,
I am using GrovePI with Intel UP Squared board. I have written small applications based on libmraa to drive these devices.
I am unable to read from GPIO/AIO ports when any device is connected on I2C. I get the following errors in the systemd journal from mraa :
*_Sep 05 06:20:49 ubuntu sudo[3355]: upsquared : TTY=pts/1 ; PWD=/home/upsquared/GrovePi/mraa_impln/grove-lightsensor ; USER=root ; COMMAND=./grove-lightsensor_*
*_Sep 05 06:20:49 ubuntu grove-lightsensor[3356]: calling mraa_init_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: libmraa version v1.9.0 initialised by user 'root' with EUID 0_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: testing log functionality_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: Adding i2c bus found on i2c-5 on adapter i2c_designware.1_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: Adding i2c bus found on i2c-4 on adapter i2c_designware.0_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: up2: kernel pinctrl driver available_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: libmraa initialised for platform 'UP2' of type 16_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: calling mraa_init_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: i2c_init: Selected bus 0_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: mraa: Added GrovePi subplatform_*
*_Sep 05 06:20:49 ubuntu libmraa[3356]: aio: Using sub platform_*
*_Sep 05 06:20:50 ubuntu libmraa[3356]: i2c5: write: Access error: Connection timed out_*
*_Sep 05 06:20:50 ubuntu libmraa[3356]: grovepi: failed to write command to i2c bus /dev/i2c-5_*
*_Sep 05 06:20:53 ubuntu libmraa[3356]: i2c5: write: Access error: Connection timed out_*
*_Sep 05 06:20:53 ubuntu libmraa[3356]: grovepi: failed to write command to i2c bus /dev/i2c-5_*
*_Sep 05 06:20:56 ubuntu libmraa[3356]: i2c5: write: Access error: Connection timed out_*
*_Sep 05 06:20:56 ubuntu libmraa[3356]: grovepi: failed to write command to i2c bus /dev/i2c-5_*
*_Sep 05 06:20:59 ubuntu libmraa[3356]: i2c5: write: Access error: Connection timed out_*
*_Sep 05 06:20:59 ubuntu libmraa[3356]: grovepi: failed to write command to i2c bus /dev/i2c-5_*
However, I am able to connect the devices (for instance LED) and able to write. Is there any known limitation/interference on I2C bus that causes the problem to read from the ports when any device is connected on I2C?
We don’t have an UP Board to test with, but what does i2cdetect (possibly i2cdetect -y 1) tool report? If there’s a problem with it, then it should come from UP drivers. Are you using the Ubilinux distribution?
Hi Robert,
UP2 Grove IoT Development kit comes with the inbuilt distribution and i haven’t changed.
Here is the information about the distribution:
Linux 4.10.0-9-upboard #11~16.04.1 SMP Wed Oct 25 17:10:46 IST 2017
Here are the list of outputs that I get using i2cdetect:
I have connected an I2C device (temp & humidity sensor on I2C-3) to check the activity on the I2C bus. However there is no information when i check with I2Cdetect on bus 0 - 3.
Here is an output for ‘i2cdetect -y 3’ (same on bus 0, 1 & 2)
Please note that I cannot check on any of the Synopsys Designware I2C adapter as SMBus Quick Write command function is not available on these buses.
I am still unable to infer anything based on these information. Could you please help me in understanding the problem with these inputs?
In addition, I would like to mention that for driving these i2c devices using mraa (temp and humidity sensor and LCD, i2c_init was done on bus 0 only(mraa_i2c_init), though i had connected them on I2C-3 and I2C-2 respectively).
Would the new version of firmware address such i2c problems? Also, note that if i connect LCD device only (on I2C bus), there is no problem.
To conclude, the problem arise only with TH02 sensor being connected on I2C along with other devices on GPIO/AIO.
The GrovePi doesn’t act as an I2C master, that’s the Raspberry Pi’s job and hence, the lost arbitration is a not a matter that fits in this scenario.
Now, one suggestion might be to slow down the bus from the current speed it runs at. What speed does it run at by the way?
Anyway, I’m pretty sure the UP board is capable of working with most of the Raspberry Pi-compatible boards/devices, but there may still be problems with its drivers. One example is that the GrovePi works fine on the Raspberry Pi and yet, it has got problems on the UP board - this tells me there has got to be something wrong with the UP board’s setup/hardware/drivers.
Just to spin some ideas here, you might be interested in using a software I2C implementation and bind that to other ports that don’t change the behavior of that GPIO pin you’re using for other stuff. Or you could go with another temperature sensor.
Thank you for providing the detail explanation. I will be executing the same software on Raspberry PI shortly as we are looking at multiple platforms. So, would like to check with the default configuration instead of changing them for every platform.
Will update once i test them on Rasberry PI.
By saying, " So, would like to check with the default configuration instead of changing them for every platform” I meant with the default configuration that is set as part of mraa initialization.
I tried with the same implementation(using GrovePI+ based on mraa) on Raspberry PI, see the same problem. Though Temp&Humidity sensor works well, rest of the other components as mentioned above doesn’t seem to respond
To conclude, its the same behavior on UP2 and Raspberry PI boards that uses mraa.
I have attached the link to a response that i heard from the team working on mraa:
So using mraa, regardless of the used platform (be it RPi or UP2), doesn’t work when you want to use other components along with the DHT sensor.
I’ve got an idea that can be the closest to what we can give at the moment. You can use our beta version of the GrovePi’s firmware, the v1.3.0 that has a multitude of fixes in it and see if that works on the RPi. If it’s a green tick, then you can move on to UP2.
If not, then I think we gotta take a more in-depth look at this issue.
Here’s the post you need to look at to set-up the beta version.
Please let us know if this worked for you or it didn’t.
