Intel® Makers
Intel® Edison, Intel® Joule™, Intel® Curie™, Intel® Galileo
Welcome - This is a Peer-to-Peer Forum only. Intel has discontinued these products but you may find support from other customers on this Forum
9872 Discussions

I2C not working any more mraa / upm bug or hardware problem

New Contributor I

Hi all,

I did some posts and comments some weeks ago to share difficulties using I2C bus on Edison Arduino and mini breakout. Some weeks ago I was finally able to properly use HTU21DF or BM180 sensors on I2C bus but never succeeded in using both on the same bus. Now the situation is even worse I cannot detect the sensors that were working few weeks ago. Here is the situation.

I am using an HTU21DF sensor that works properly with an arduino and a breadboard with HTU21DF and BM180 on the same bus with pullups and voltage converter that also works with the arduino.

I am using a edison with arduino breakout fully reinstalled last week. mraa and up libs are compiled from github cloned and pulled sources :

>>> mraa.getVersion()


Tu be sure that there is no low level problem I have reconfigured the I2C according to

echo 28 > /sys/class/gpio/export

echo 27 > /sys/class/gpio/export

echo 204 > /sys/class/gpio/export

echo 205 > /sys/class/gpio/export

echo 236 > /sys/class/gpio/export

echo 237 > /sys/class/gpio/export

echo 14 > /sys/class/gpio/export

echo 165 > /sys/class/gpio/export

echo 212 > /sys/class/gpio/export

echo 213 > /sys/class/gpio/export

echo 214 > /sys/class/gpio/export

echo low > /sys/class/gpio/gpio214/direction

echo high > /sys/class/gpio/gpio204/direction

echo high > /sys/class/gpio/gpio205/direction

echo in > /sys/class/gpio/gpio14/direction

echo in > /sys/class/gpio/gpio165/direction

echo low > /sys/class/gpio/gpio236/direction

echo low > /sys/class/gpio/gpio237/direction

echo in > /sys/class/gpio/gpio212/direction

echo in > /sys/class/gpio/gpio213/direction

echo mode1 > /sys/kernel/debug/gpio_debug/gpio28/current_pinmux

echo mode1 > /sys/kernel/debug/gpio_debug/gpio27/current_pinmux

echo high > /sys/class/gpio/gpio214/direction

Then if I check the bus it does not detect the sensor(s) in any configuration

i2cdetect -y -r 6

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

When I try to connect to the sensor with python upm modules I get this error :

>>> import time

>>> import mraa

>>> import pyupm_htu21d

>>> bus = 6

>>> tempAddress = 0x40

>>> temp = pyupm_htu21d.HTU21D(bus, tempAddress)

>>> temp.resetSensor ()

>>> temp.sampleData()

Traceback (most recent call last):

File "", line 1, in

File "/usr/lib/python2.7/site-packages/", line 171, in sampleData

return _pyupm_htu21d.HTU21D_sampleData(self)

ValueError: UPM Invalid Argument: Unknown error in I2c::readReg()

I have spent plenty hours to try to get this to work without any progress, I have read many threads here with no clue or help to solve my problem. Nobody seems to experience the same defect, could it be a problem with my Edison but in that case why both mini and Arduino breakout do not work...

Please heeeeeeeeeeelp ;-(


0 Kudos
21 Replies
New Contributor I


I forgot to tell that the sensors are not detected when the breakout is used with the arduino IDE. Hardware problem ?


Community Manager

Did you measure anything on the I2C lines?

If you do not have an oscilloscope try an infinite loop and measure the frequency of the SCL line using a multimeter

If you even do not have a multimeter you can use your arduino and count edges


New Contributor I

Thanks Flo1991 , as you guess I have no oscilloscope at hand and I am not sure that my "amateur" multimeter can measure frequencies. I come from the code side and I can more easily check Cooper132 solutions...

If you can give me links to read on how to count edges I will try. Do you know if i2cdump program can do the trick.

Many thanks

New Contributor I

I was getting the same errors in my c++ code yesterday as well, after I updated to mraa v1.0.0.

I haven't worked with the python side of mraa, so I don't know if this applies here as well, but for c++ there was a recent commit

that introduced exceptions on i2c read errors, instead of simply ignoring them.

In your code you can just handle these exceptions (std::invalid_argument in c++, but that is probably somewhat different for python).

Here is how to do that if you don't know: 8. Errors and Exceptions — Python 3.5.1 documentation

Of course, the fact that you are getting a read error at all hints to there being some kind of hardware problem, maybe a faulty connection to one of your sensors?



Edit: having a quick look at the mraa python source, it is in fact just a swig wrapper interface to the c++ api.

In your code you can just do


# I2C read code that fails

except ValueError:

pass # or some other stuff you might want to do on read error

New Contributor I

Many thanks Cooper132 for you answer and observations. I will investigate your hints and that will at least remove the problem or the doubt on the hardware. But I really think that the commit you pointed out is a killer modification.

I am using upm libs to connect the sensor and if you are right that means that upm_htu21df librairy should be corrected and probably most of the programs using I2C in their upm lib....

I'll let you know ASAP if things have evolved.

Tanks again.

New Contributor I

Yes you are right, this could (should?) be handled in the upm code.

And, looking at the relevant file L222 upm/htu21d.cpp at master · intel-iot-devkit/upm · GitHub , it does not seem to be handled at the moment.

Maybe you might want to open an issue there to get it fixed, but I don't know how fast that would be.

New Contributor I

Cooper132 I have contributed on upm and I will open an issue on github but iI will try also to fix it by myself so I can propose a pull request, even if it is not fully resolved, and one can hope that one of the gurus will take over

From what I remember I2c::readReg() can be amended in htu21df source when it calls functions from mraa; there must have à bug in the call of lw level mraa functions described here :

I cannot check that right now, I am installing mraa and upm on a raspberry pi to rule out the Edison hardware problem. I guess that with the raspi I will not be able to use the sensors either.


Community Manager

For rough frequency measurements with an arduino you can use this lib: FreqCount Library, for Measuring Frequencies in the 1 kHz to 5 MHz Range


Community Manager

Hi GerardVidal,



Let us know if you opened an issue in the github for UPM. Also, tell us about your latest tests and results.


Have you been able to count the edges or to do more measurements?





New Contributor I


Sorry for the delay. Thanks again to Flo1991 for the links (I was not able to use the one gven but found another link to FreqCounter that works)

I have tested SCL with arduino sketch FreqCounter

Results are not clear

The first test gave frequencies that seem correct but vary after some time (measurement interval is 2s here :

508 Freq: 52

509 Freq: 46

510 Freq: 48

511 Freq: 46

512 Freq: 53

513 Freq: 59

514 Freq: 56

515 Freq: 52

516 Freq: 61

517 Freq: 57

518 Freq: 9

519 Freq: 6

520 Freq: 8

521 Freq: 12

522 Freq: 14

523 Freq: 7

524 Freq: 12

525 Freq: 43

526 Freq: 46

527 Freq: 44

528 Freq: 59

529 Freq: 52

Unfortunately another test showed that frequencies were bad

70 Freq: 5

71 Freq: 5

72 Freq: 6

73 Freq: 5

74 Freq: 6

75 Freq: 6

76 Freq: 6

77 Freq: 7

78 Freq: 5

79 Freq: 5

80 Freq: 6

81 Freq: 6

82 Freq: 5

After a reboot the frequencies climbed up a little again but for a limited time.

128 Freq: 6

129 Freq: 5

130 Freq: 36

131 Freq: 19

132 Freq: 19

133 Freq: 21

134 Freq: 21

135 Freq: 38

136 Freq: 32

137 Freq: 41

138 Freq: 36

139 Freq: 5

140 Freq: 5

I do not know what does that exactly means but it seems that my i2c bus is dead or almost....

But if I use the edison arduino breakout with the arduino IDE it works properly and I get good measurements for pressure, temperature and hygro ! Which may demonstrate that the I2c bus works properly. Could it be a kernel issue on the edison?

Is there any hope to get back this Edison to work or should I buy a new one?

Thanks for your help and interest.

Community Manager

As you can see I2C is not working, the frequency should be several kHz (100 or 400, depending on the bus settings).

You say everything works using the edison with the arduino ide everything works, but by using the mraa bib you don't get any values.

So it is a software problem, first you may try to reflash the image.

A second thing you should try is to communicate over i2c without using any part of mraa.


New Contributor I

Some more information

thanks Flo1991 for the expertise !

here is some more information.

I have built on a breadboard a circuit with HTU21D, BMP180 and MPL115A2 with pullup resistors on 5V high voltage side of an Adafruit Bi-Directional level shifter and measurements on 3.5V side. Measurement yield correct values with an arduino on the 3.5V side.

On the Edison arduino Breakout, the same circuit is not functional, none of the captors send good measurements and some are even not initialized. BUT if I connect sensors one by one I get correct meaurements.

I will now follow your advice and flash again the Edison !

Community Manager

Do you have some more information about your hardware?

Can you measure the voltage on the sda/scl line when no communication is done (on both sides, 3V3 and 5V). Furthermore you should measure the resistance between sda to 3V3, sda to 5V, scl to 3V3, scl to 5V (DISABLE ALL POWER CONNECTIONS SO EVERYTHING IS OFF WHEN YOU MEASURE RESISTANCE). Maybe there is a problem with the pull-up.

At the software side you can try to communicate directly using linux without mraa: Programming the pcDuino - xGoat – Using I2C from userspace in Linux


New Contributor I

Thanks for your time.

Voltage on sda and scl is 5.01V on one side and 3.45 V on the other side .

Concerning the resistance I cannot get any measurement with SDA(A4) or SCL(A5) against 3.5V and 5V. You are probably right on the fact that the pullup resistors of the Edison are burnt which indicates also that probably the i2c bus has suffered some misuse...

Is it possible to add external pullup resistors to replace? If yes which value suits better ?

I will anyway flash the new image and see if anything chages.

I'll let you know

Thanks again

Community Manager

No problem, what do you mean by saying "Concerning the resistance I cannot get any measurement"?

What is the resistance? Around 0 ohms, around several mega-ohms, whatever ?


New Contributor I


Here is a milestone on the question

I am using an Genuino UNO as reference and I am working on an Edison Arduino Breakout, my computer is linux Debian stretch (testing)


  • HTU21D captors works perfectly with the breakout if connected to the Genuino IDE
  • HTU21D captor does not work with mraa/upm and a python program
  • combination HTU21D BMP180 and MPL115A2 does not work with IDE nor with mraa/upm in python

First investigations were made on the i2c SCL SDA

  1. Using Genuino and arduino sketch FreqCounter I got the following frequencies
    • variable values ranging from 43 to 61 (step is default from the program 100ms)
    • then freq ranging from 5 to 7
    • then a burst on 20 second reaching 43

Flo1991 suggested that i2c was not working ans asked for Voltage and resistance measurements

  • Using multimeter
    • we got 5.01V on one side and 3.45 V on the other side of the voltage shifter connected to the three sensors
    • the resistance is not measurable (infinite ? see below) between SCL or SDA and 3.5V or 5V pins

It seems to me that my i2c bus has been damaged, can anybody confirm this hypothesis ? I have another Edison (minibreakout) with the same symptoms then I think that the problem may come from a bad wiring or any action I may have made; can anybody tell me what can damage the i2c to prevent another error because I thought I had been cautious. Can anybody suggest a solution to bring back the i2C to life? It could be possible because one sensor on the bus works with the IDE, which brings us to the suspicion on software.

I flashed the image with no effect and no change on the behavior.

Cooper132 pointed out a recent commit that may influence the behaviour. This proposal leads us to investigate source code from upm more precisely on I2c::readReg() function that is used by many programs including HTU21D. This is the task on my agenda now

Resistance measurements :

When I switch on the multimeter the display shows :

1 .

If I touch the two conectors I get 0.00

When I link SDA or SCL with 3.5V or 5V nothing changes : the display remains 1 .

Which means I think that the circuit is opened.... No resistor or burnt resistor. Is that right?


Community Manager

On the edison side everything seems to be fine, the pull-ups are software controlled. So a very high resistance is good (because the edison is turned off, the pull-ups are not active).

You can find this on the schematic( ), sheet 6, U17, IO1.5 and IO1.4.

Do you use adafruit sensor boards?

What happens if you use the BMP180 and MPL115A2 together on the bus?

Can you post your hardware setup?


New Contributor I

Do you mean that you think that the Edison i2c is not damaged

I am using Adafruit sensors, I have not been able to interfere with MPL115A2 with mraa/upm because the code is not available and MPL3115A2 yields error message with bad device Id. As far as I remember I did all combinations with the same result (I'll check again tonight)

Here is a picture of the wiring (white is SDA yellow/green are SCL, as shown on the shifter High Voltage 5V is at the bottom and low Voltage 3.5V at the top)

If th edison i2c is Ok why i2cdetect -y -r 6 cannot detect any sensor even if just one is plugged ?

I am sorry for the work on code but I have few time for this project.

Community Manager

Refering to your wiring you should do some changes:

I suppose you mainly use the intel edison arduino board which is 3V3.

So you do not need the level shifter:

-remove the level shifter

-connect VIN to 3V3 of the HTU21D and 3V0 of the BMP180 directly to 3V3 of the edison arduino board

-connect VDD of the MPL115A2 to 3V3 of the edison

-remove your external pull-ups

Try to configure the edison sda/scl pins as gpio output and toggle them, you can connect an LED to see if it is toggeling.

If this works your edison (hardware) should be fine.


New Contributor I

Great news !

I have corrected some casts and reads on the upm library HTU21D code and miracle The Edison reads data on the i2c.

root[/home/vidal/Projets/I2C/HTU21DF] emmett.€ : python

Tapez "stop" pour arrêter les mesures, "test" pour tester le capteur

et "reset" pour le réinitialiser.

Température : Hygrométrie : Hygro Corrigée :

-10.889 112.354 117.737

-19.126 10.792 17.410

-27.363 30.323 38.177

-35.600 57.667 66.757

stop-41.091 75.245 85.158

Arrêt demandé.

I have modified the read function that is nos reading anymore the right adresses which yields wrong values (I suppose) I did that to be sure that I got rid of any potential other influence on the bug, I will amend and contribute to github.

You may wonder where the miracle is ... Just have look to the detection check on the i2C that follows:

root[/home/vidal/Projets/I2C/HTU21DF] emmett.€ : i2cdetect -y -r 6

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

No sensor is detected !!!! The HTU21D is plugged, the program can read information from a ghost sensor!

Cooper132 seems to be right the error came from the commit on the readReg (see earlier comment on this trend). I am almost back in a decent situation that I knew when I opened the Edison Arduino Box . I will spend some time before the end of the week to make acceptable corrections on the prog and make a pull request on upm github.

To answer your questions :

I used a level shifter because I have also a mini breakout and I think that it is requested for the minibreakout, I found that it was an opportunity to play with it between 3.5 and 5V of the arduino breakout.

I thought that 3V3 of the HTU21D and 3VO of the BMP180 were 3V outputs ....

I will do the test with leds as final check

Thanks for your involvment, I hope that my next message will be to declare that we reach final solution.... If you can tell why i2cdetect does not see the sensor even if it is active.