Go Down

Topic: I2C issues (Read 8100 times) previous topic - next topic


Hi Erik

Just hooked up the MPU-9255 that has a BMP180 on board as well.  First run only showed the accel/gyro address.  Wasn't sure it was going to pick up the mag since its a pass thru to the accel/gyro core.  It didn't pick up the pressure sensor either.

I went ahead and loaded my version of the FreeIMU lib and it read the magnetometer no problem

I then reloaded the I2CScanner and guess what - it picked up all three sensors - accel/gyro, magnetometer and pressure.  Here is a shortened version of the results:

TIME   DEC   HEX      50   100   200   250   400   500   800   [KHz]

15327   9   0x09      .
15335   10   0x0A      .
15341   11   0x0B      .
15353   12   0x0C   V   = Magnetometer address (AK8963)
15991   102   0x66      .
15998   103   0x67      .
16011   104   0x68      V   = Accel/Gyro (Believe its a MPU-6500 or 6550)
16018   105   0x69      .
16025   106   0x6A      .

16110   118   0x76      .
16123   119   0x77      V  = BMP180 pressure sensor
16130   120   0x78      .
16138   121   0x79      .

If I had to make a prediction i would not make any guarantees on the reliability of the I2C bus.  Definitely think there is a problem with the I2C library.  Could be related to the outstanding pull request.  Wish our moderator would jump in.

Let me know how it works out for you.



Hello Mike,

I think you're right, I also had the same impression that it is a software issue like wire library or something else...

As soon as arrives to me the MPU 9255, I will let you know immediately! (hoping it works)

No other forum user has this problem?




Mar 09, 2016, 03:57 pm Last Edit: Mar 09, 2016, 08:07 pm by Merlin513
Hi Erik

Never had a problem with any other board - and not noticed it any other forum but then I never really looked.  Arduino 101 is a new board and looks like they are still working out the bugs.  Not sure they really did a lot of testing the way some makers would use the board.  There is definitely a wearable flavor to the whats out there but that is probably because the Curie was meant for the wearable environment - I THINK. 

I had a similar problem with the Intel Galileo when it first came out, I2C issues, but I think that is because of the way they implemented the I2C bus in hardware, don't think its the same design though.  Haven't really used it much because of that - maybe with the libs for it the problem is fixed.


UPDATE: Ok.  Did a little search and found the Due had similar I2C issues.  Heres the link: http://forum.arduino.cc/index.php?topic=146802.15. Other boards seem to have the similar problems like Leonardo and all related back to the twi or wire or I2c libs.

UPDATE2 - 3/9/16.  Last night it all worked fine.  Now today I had to run the scanner three times to find the accel/gyro and pressure sensor.  Never picked up the magnetometer.  The new core did not include facchinm bug fix request.  Need this fixed now.


Hello Mike,

I tried to look at the link about arduino due but unfortunately it did not help me...

I can confirm also i have tested a MPU6050 HMC5883L BMP180 (GY-87) with multispeed i2c scanner and it does not find anything!

I understand that is a board that has been released recently, we will wait to be fixed the problem!




Hi Erik

I just did another post to try and bring it to the forefront but have not heard anything.  Like you said will have to wait and see if they ever get around to fixing it.  For now think I will just have to put the 101 on the side and work on something else.

Happy coding


Mar 13, 2016, 08:41 pm Last Edit: Mar 14, 2016, 12:03 am by Willeroo
Hello. I am new to this forum. Tinkering with a couple of OSEPP Uno R3+ Arduino compatible boards and several sensors/shields for the past 3 months has been great fun. So I picked up an Arduino 101 last week to check out a real certified Duino.

During comparison tests yesterday and today, I noticed a significant difference between the Uno and 101, and suspect that I2c communication speed may be the cause.

For the comparison tests, I used an Adafruit MCP4725 DAC Breakout Board that arrived in the mail yesterday. It's my first and only external I2C device, so my ability to test I2C communications is limited. The breakout is hard-wired directly to the Arduino board separately for each comparison test. Both Arduinos were powered by USB during testing (board voltages confirmed by DMM). But plugging a 9v battery into the barrel jack gives same results. As far as I can tell from the Arduino IDE, I have the latest board/core drivers and relevant libraries. Also, the following results are equivalent with IDE ver. 1.6.7 yesterday, and IDE ver. 1.6.8 today.

This MCP4725 breakout does establish communication with both Arduino boards. That's not a problem. The issue appears to be communication speed. The Uno board appears to communicate roughly 7 times faster over I2C than the 101 board. At least, that's one possible explanation for the following observations. Using Adafruit's MCP4725 library and example codes, I measured sine and triangle wave signal frequencies at the DAC's output (no load) using a reliable Fluke 298 DMM. Unfortunately, I don't have an oscilloscope to analyze the signals further.  Here are the results:

                              Freq (Hz)
                         Sine           Triangle
Uno:                  26.0              0.811

101:                   3.8               0.119* 

Uno/101 ratio:     6.8                6.8
*Triangle wave frequency with the 101 appears to be too slow or signal is too erratic for the DMM to report Hz, so I measured and averaged three peak-to-peak cycle times (8.4sec) and calculated Hz).

Test results for both wave types are the same whether the DAC breakout is connected to the Arduino's 3.3 or 5v pins, and are also the same whether the breakout is connected to the 4/5 or SCL/SDA pins, as you'd expect.

It's interesting that my Uno results are approximately twice what Adafruit anticipates for the TWBR tweak. Maybe there's a reason for a doubling of the effect in this test application.

Given that the Quark/Curie processor is advertised to be more full-featured and faster, my assumption is that process speed isn't the issue here. Two possible explanations come to mind:

1) I2C communication speed.   Is it possible that coding magic in Adafruit's MCP4725 library that's reported to increase the Amtel's I2C communication speed from 100 to 400 kHz (TWBR = 12;// 400 khz) may work for the Uno's microprocessor, but not for the 101's? If so, is there a related command for the Intel chips' I2C communication rate?

2) I2C conflicts. As far as I know, the Uno has no on-board I2C devices. The MCP4725 uses default address 0x62. I haven't reviewed documentation for the 101's Bluetooth and accelerometer/gyro devices. Might they conflict with the MPC4725, and/or might they occupy some I2C buss time?  If so, is it possible to turn off Bluetooth and accelerometer/gyro when not in use?

I'm a long-term consumer/fan of Intel processors, and understand that Quark chip documentation may be available soon (this month). My questions may need to wait til then. Meanwhile one or more of you might have suggestions and/or alternative interpretations.

For further detail about the MCP4725 breakout board, Adafruit's tutorial is available at: https://learn.Adafruit.com/downloads/pdf/mcp4725-12-bit-dac-tutorial.pdf, including a link to their library and example sketches at the bottom. The triangle wave sketch (the shorter of the two) is repeated below. Obviously, please observe Adafruit's copyright and license for library and sketches).

P.S. I'm using the new 1.05 core.

   @file     trianglewave.pde
   @author   Adafruit Industries
   @license  BSD (see license.txt)

   This example will generate a triangle wave with the MCP4725 DAC.   

   This is an example sketch for the Adafruit MCP4725 breakout board
   ----> http://www.Adafruit.com/products/935

   Adafruit invests time and resources providing this open source code,
   please support Adafruit and open-source hardware by purchasing
   products from Adafruit!
#include <Wire.h>
#include <Adafruit_MCP4725.h>

Adafruit_MCP4725 dac;

void setup(void) {

 // For Adafruit MCP4725A1 the address is 0x62 (default) or 0x63 (ADDR pin tied to VCC)
 // For MCP4725A0 the address is 0x60 or 0x61
 // For MCP4725A2 the address is 0x64 or 0x65
 Serial.println("Generating a triangle wave");

void loop(void) {
   uint32_t counter;
   // Run through the full 12-bit scale for a triangle wave
   for (counter = 0; counter < 4095; counter++)
     dac.setVoltage(counter, false);
   for (counter = 4095; counter > 0; counter--)
     dac.setVoltage(counter, false);


Hi Willeroo

Great analysis.  Think it points out that there really is an issue with I2C implementation.

Check out the first post on page 2 of this thread.  It discusses changing the I2C bus speed from 100 Hz to 400Hz. 

The Curie IMU should not be interfering with the I2C bus since they have it hooked up to the internal SPI bus = but I can not be 100% sure of how it is all implemented :)

There is another post that discusses the I2C bus speed - how to change.  Just in case you want to retry. 

As for the bus speed - not sure if that is the issue but I do not know enough about how this all works - it may be more of an issue on how I2C is implemented on the 101 vs the Uno.  In other posts it is becoming clear that there is a lot more development work that is needed on the 101.

I am definitely going to check out the MCP4725 breakout board.

PS.  Welcome to the forum.


Thank you for your quick reply, Mike, and for those two scoops about Arduino 101 I2C bus speed changes. I obviously missed them while searching around. Will check them out and report back whether it improves results with my test setup.

Would enjoy hearing your experience with the MCP4725. There are a few options available on the net. This is a 12-bit. Others, I think are 8 or 10. My initial though was to try it out as an analog feed feed into a low power audio amp chip, but I'm a bit apprehensive after seeing how slow I2C communication is. I've read that the Due's DAC's have been used for that purpose, but have also read that an external DAC might work better.

Maybe we should start a MCP4725 thread if there is enough interest. There doesn't appear to be one yet on this forum, but there's a lot of info at other sites.



Hi Bill

Here is the link to the post I mentioned - just found it: http://forum.arduino.cc/index.php?topic=371827.0

Not that familiar with DAC to Analog so I have to figure all the things that I could do with it first.  Right now I just wish I2C would work. :)



Mar 14, 2016, 04:35 pm Last Edit: Mar 15, 2016, 12:02 pm by Merlin513 Reason: Corrected file name
Erik and Bill

just posted this in another thread and re=posting here for reference:

Hi facchinm

Came up with an easy way, I think, to make the chose between fast or slow clock speed an option.  Here are the changes:

In Wire.h

Add the following line to public:  
Code: [Select]
void begin(bool i2c_clock);

In Wire.c
Add the following function call:
Code: [Select]
void TwoWire::begin(bool i2c_speed)
 init_status = i2c_openadapter(i2c_speed);

edit the existing TwoWire::begin() to
Code: [Select]
init_status = i2c_openadapter(false);

In i2c.h
change the i2c_openadapter line to read:
Code: [Select]
int i2c_openadapter(bool i2c_speed);

In i2c.cpp
delete line i2c_cfg.speed and insert:

Code: [Select]
if(i2c_speed == true) {
 i2c_cfg.speed = I2C_FAST;
 } else {
 i2c_cfg.speed = I2C_SLOW;

Simple usage:

For slow i2c clock just use wire.begin() or wire.begin(false).

For fast i2c_clock just use wire.begin(fast)

It compiles with no problem but not 100% sure its taking.  I don't have a scope so I can not test. Hope someone can verify and maybe we can get them to incorporate it.



Mar 15, 2016, 06:15 am Last Edit: Mar 15, 2016, 06:32 am by Willeroo

The i2c.c patch in your http://forum.arduino.cc/index.php?topic=371827.0 post had no effect on my
Arduino 101 setup; communication rate remained miserably slow for both Adafruit codes. Tried to report that yesterday, but lost my draft twice due to internet connection glitches and gave up. I figured out how to turn on auto-save today. 

Will give your latest Wire.h and i2c patches a try and report back.

Someday when you have time, I would enjoy hearing how you think IDE uses Intel's core libraries while compiling code, and whether IDE detects and over-rides Arduino library features that aren't compatible with the Intel core.

Thanks again,



Erik and Bill

just posted this in another thread and re=posting here for reference: .....................................................
I modified my libraries per your post today. Could not find "i2c.cpp". Did you mean "i2c.c"?

Will test this on Uno and Arduino 101 setups with Adafruit MCP4725 breakout obard and sketches. Will your changes conflict with or overlap the TWBR adjustment in Adafruit_MCP4725.cpp lines 67 through 70? I'm wondering if this might block my test setup from showing a difference with your mods to Wire and Intel's i2c libs. 

#ifdef TWBR
  uint8_t twbrback = TWBR;
  TWBR = ((F_CPU / 400000L) - 16) / 2;    // This line sets i2c bus to 400kHz




Yes you are correct for the Arduino 101 the file is i2c, my mistake - just real use to working with c++ files :)

The corelibs for the Uno and other AVR boards are totally different.  The code snippet that you reference is for the AVR boards so there should be no affect.  Also, its set up so that you have to define the TWBR somewhere in your code or the library - not familiar with the adafruit library so you would have to verify if the defined it in the library itself or you need to define it - my guess is that you can define it in the .h file of the library.

Here is a snippet of code that is used in the FreeIMU library as an example - works for AVR and Teensy:

Code: [Select]
#if defined(__AVR_ATmega128) || defined( __AVR_ATmega2560__ ) // only valid on AVR, not on 32bit platforms (eg: Arduino 2, Teensy 3.0)
    if(fastmode) { // switch to 400KHz I2C - eheheh
      TWBR = ((F_CPU / 400000L) - 16) / 2; // see twi_init in Wire/utility/twi.c
  #elif defined(__arm__)
    if(fastmode) {
      #if defined(CORE_TEENSY) && F_BUS == 48000000
        I2C0_F = 0x1A;  // Teensy 3.0 at 48 or 96 MHz
        I2C0_FLT = 2;
      #elif defined(CORE_TEENSY) && F_BUS == 24000000
        I2C0_F = 0x45;  // Teensy 3.0 at 24 MHz
        I2C0_FLT = 1;
  #elif defined(__SAM3X8E__) //Arduino Due
if(fastmode) { // switch to 400KHz I2C - eheheh
      TWBR = ((F_CPU / 400000L) - 16) / 2;

The modifications for the Arduino 101 only works with the corelib associated with the 101 board which is in  ........  \AppData\Local\Arduino15\packages\Intel\hardware\arc32\1.0.5\cores\Arduino\cores.



This is a repost of a reply from another thread for your reference:

Hi Bill

Glad you got it somewhat working.  I finally broke down and bought a cheap USB scope and just finished running some tests with it.  SDA you can see a difference and the trace makes sense even though not great - probably need to reduce the pullups to 2k2 from 4k7. 

SCL at either speed just doesn't look right to me.  It just looks like the clock is messed up.  The scope can't even get a good frequency reading.  But then again I am not sure how to use a scope

Here is a link to all the screen shots.

Think I am done with this board for a while until someone from Intel lets us know whats going on with I2C, not sure anymore if the internal SPI from the IMU is interfering with the I2C timing.

As for the uno being faster for some tasks, don't know.  Think it may be more of a maturity of the board.

UPDATE:  After I posted this thought I would just test the 5883L by itself without the BMI160.  Guess what - now the 101 does not even find the magnetometer.


Go Up