# I2C not working as expected

**URL:** <https://community.particle.io/t/i2c-not-working-as-expected/1997>\
**Category:** Troubleshooting\
**Created:** [January 13, 2014, 1:37am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997 "2014-01-13T01:37:48Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![tforster](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/tforster/32/20943_2.png) [@tforster](https://community.particle.io/u/tforster)\
**Post date:** [January 13, 2014, 1:37am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/1 "2014-01-13T01:37:48Z")

</div>

Hi, I’m trying to communicate with a BlinkM via I2C with absolutely no success. Since nothing works I figure I’m missing a fundamental step. When I run the code below and call the function I do get the expected return value of 4. However, nothing changes on the BlinkM. I have the same sketch, modified to remove Spark specifics, running successfully on an Arduino Uno.

My wiring is as follows:

```
A2 -> -
A3 -> +
D0 -> D
D1 -> C

```

Spark Sketch:

```
void setup() {
  Spark.function("setColour", setColour);
  pinMode( A3, OUTPUT);
  pinMode( A2, OUTPUT);
  digitalWrite( A3, HIGH );
  digitalWrite( A2, LOW );

  delay(100);

  // Supposed to disable any scripts running on the BlinkM
  Wire.begin();
  Wire.beginTransmission(0x09);
  Wire.write('o');
  Wire.endTransmission();
}

int setColour(String colour) {        
    Wire.beginTransmission(0x09);// join I2C, talk to BlinkM 0x09
    Wire.write('c'); // ‘c’ == fade to color
    Wire.write(0xff); // value for red channel
    Wire.write(0xc4); // value for blue channel
    Wire.write(0x30); // value for green channel
    Wire.endTransmission();  
    return 4;
}

void loop() { }

```

Uno Sketch:

```
#include <Wire.h>;
void setup() {
  
  pinMode( A3, OUTPUT);
  pinMode( A2, OUTPUT);
  digitalWrite( A3, HIGH );
  digitalWrite( A2, LOW );

  delay(100);

  // Supposed to disable any scripts running on the BlinkM
  Wire.begin();
  Wire.beginTransmission(0x09);
  Wire.write('o');
  Wire.endTransmission();
}

int setColour(String colour) {        

}

void loop() { 
    Wire.beginTransmission(0x09);// join I2C, talk to BlinkM 0x09
    Wire.write('c'); // ‘c’ == fade to color
    Wire.write(0x00); // value for red channel
    Wire.write(0x00); // value for blue channel
    Wire.write(0xff); // value for green channel
    Wire.endTransmission();  

}
```

---

<div class="post-metadata">

**Author:** ![zachary](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/zachary/32/20717_2.png) [@zachary](https://community.particle.io/u/zachary)\
**Post date:** [January 13, 2014, 1:42am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/2 "2014-01-13T01:42:00Z")

</div>

Hey @tforster—check out this thread

> **[I2C: 7 or 8 Bit Addresses? \[Fixed! Pull Request Submitted.\]](https://community.particle.io/t/i2c-7-or-8-bit-addresses-fixed-pull-request-submitted/1328)**
>
> I’m working with a little OLED display here, which has a 7-Bit address of 0x27. Normally, this is what you’d use with Arduino and what’s listed in the Spark Docs. Unfortunately, according to both my Logic 16 and Bus Pirate, it’s trying to write to...

I still haven’t merged @timb’s pull request—should happen sometime this coming week.

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [January 13, 2014, 1:47am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/3 "2014-01-13T01:47:48Z")

</div>

Basically your address should be like this:  
`Wire.beginTransmission(0x12); // 0x09 shifted one to the left`

And your wiring should be:

```
GND -> - (PWR -)
Vin -> + (PWR +) for 5V
D0 -> D (SDA)
D1 -> C (SCL)

```

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [January 13, 2014, 2:41am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/4 "2014-01-13T02:41:15Z")

</div>

Also after looking at the datasheet again, pretty sure there are no pull up resistors on the D (SDA) and C (SCL) lines, so you’ll need to add minimum 10k ohms on each one to Vin. You can go as low as about 2.2k ohms.

---

<div class="post-metadata">

**Author:** ![tforster](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/tforster/32/20943_2.png) [@tforster](https://community.particle.io/u/tforster)\
**Post date:** [January 13, 2014, 3:39am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/5 "2014-01-13T03:39:40Z")

</div>

@zachary Thanks for the pointer. I’m going to read that in a second to understand _why_ this now works 😄

@BDub Thank you for the detailed pinnouts and recco for pullup resistors. You made it really easy for me to fix and after reading @zachary recco’d post I’ll know why this worked.

Thanks guys, as a long time software developer that is new to microcontrollers I know that this is a real noob question and I appreciate the quick response.

---

<div class="post-metadata">

**Author:** ![timb](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/timb/32/1913_2.png) [@timb](https://community.particle.io/u/timb)\
**Post date:** [January 13, 2014, 3:44am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/6 "2014-01-13T03:44:42Z")

</div>

Actually, I’ve had to go down to 470 Ohm for the pullup resistors on a lot of devices. I know that there’s no internal weak pullups being activated on the I2C lines and I’m working on trying to activate those. It also almost seems like the I2C interface isn’t entering Open Drain mode at times, which would explain why I need such low value resistors for the pullups.

---

<div class="post-metadata">

**Author:** ![timb](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/timb/32/1913_2.png) [@timb](https://community.particle.io/u/timb)\
**Post date:** [January 13, 2014, 4:03am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/7 "2014-01-13T04:03:55Z")

</div>

@tforster To put it simply, I2C addresses are 7-Bit in length. In reality, each single I2C device _actually_ uses two separate addresses, one for _read_ and one for _write_. These read and write addresses are the 7-Bit address with a 0 or 1 added to the LSB.

```
0b0100111 in hex => 0x27
0b01001110 in hex => 0x4E
0b01001111 in hex => 0x4F

```

If _0x27_ is my 7-Bit Address, you can see adding a 0 to the end creates the write address of _0x4E_ and adding a 1 creates the read address of _0x4F_. This is why I2C addresses are between 0 and 127: `127 in binary => 0b1111111` or _seven ones_. (_127_ is the highest number you can achieve with only _seven bits_.)

Essentially, the underlying STM32 I2C code isn’t correctly shifting the 7-Bit address to the left before adding the read or write bit right now. I’ve fixed it, but until they pull the patch in you’ll need use the full 8-Bit read or write address.

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [January 13, 2014, 4:41am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/8 "2014-01-13T04:41:12Z")

</div>

Yeah I was kind of just giving a range that should work well without anyone reading it having to think too much about it. I was using 10k ohm pull ups today with the DS1307 RTC and it was working great. I’ve never had to go any lower than 2.2k ohm on designs with 8 foot cable length between master and slave devices.

Also my recommendation was to prevent accidentally over-driving the outputs. (max 20mA).

And to prevent reading something like this to calculate it properly:  
[http://www.edn.com/design/analog/4371297/Design-calculations-for-robust-I2C-communications](http://www.edn.com/design/analog/4371297/Design-calculations-for-robust-I2C-communications)

But this ^ is a good read by all means give it a go!

😄

---

<div class="post-metadata">

**Author:** ![timb](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/timb/32/1913_2.png) [@timb](https://community.particle.io/u/timb)\
**Post date:** [January 13, 2014, 4:54am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/9 "2014-01-13T04:54:43Z")

</div>

Oh yeah, totally. I was just mentioning it to let people know they may have to go a bit lower right now.

---

<div class="post-metadata">

**Author:** ![tforster](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/tforster/32/20943_2.png) [@tforster](https://community.particle.io/u/tforster)\
**Post date:** [January 15, 2014, 5:05pm UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/10 "2014-01-15T17:05:40Z")

</div>

FYI everyone, shifting the address worked as expected and I have full control of the BlinkM as a result. And FWIW I’m using 10K pull ups.

Thanks for everyone’s help and responses.

---

<div class="post-metadata">

**Author:** ![zachary](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/zachary/32/20717_2.png) [@zachary](https://community.particle.io/u/zachary)\
**Post date:** [January 20, 2014, 4:28am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/11 "2014-01-20T04:28:48Z")

</div>

Just an update on the status of @timb’s pull request. I merged it into master on the 16th. Next time we bring the compile-server2 branch up to date (sometime this week), I2C addresses will be automatically shifted when compiling in Spark Build.

> **[particle-iot-archived/core-common-lib](https://github.com/particle-iot-archived/core-common-lib/network)**
>
> Common library for projects that use the Spark Core with the CC3000 - particle-iot-archived/core-common-lib

---

<div class="post-metadata">

**Author:** ![Soulhuntre](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/soulhuntre/32/2106_2.png) [@Soulhuntre](https://community.particle.io/u/Soulhuntre)\
**Post date:** [January 20, 2014, 4:36am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/12 "2014-01-20T04:36:58Z")

</div>

@zachary - that’s awesome news!

Now if I could just get I2C to work reliably 😄

Ken

---

<div class="post-metadata">

**Author:** ![timb](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/timb/32/1913_2.png) [@timb](https://community.particle.io/u/timb)\
**Post date:** [January 20, 2014, 5:22am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/13 "2014-01-20T05:22:49Z")

</div>

> [@Soulhuntre](#):
>
> Now if I could just get I2C to work reliably

That's on my, uh, "Personal Sprint" list. I'm systematically rewriting the entire I2C system to function with DMA and not perform any sort of blocking.

Right now, the I2C system isn't _horrible_ but I think the CC3000 issues are really dragging everything down. I think having I2C, SPI and UART all using DMA after the CC3000 drivers are stabilized will more or less make the comms bulletproof.

Hang in there, this platform is just a baby right now, but it's growing quickly! Keep in mind the Spark Team is still working hard to iron out some pretty critical bugs. People like myself, @BDub and others aren't getting paid to work on this stuff, but we do it anyway to make the platform—and community—better. We just can't do it full-time (although it's been like that for me lately). 😄

---

<div class="post-metadata">

**Author:** ![Soulhuntre](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/soulhuntre/32/2106_2.png) [@Soulhuntre](https://community.particle.io/u/Soulhuntre)\
**Post date:** [January 20, 2014, 6:20am UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/14 "2014-01-20T06:20:47Z")

</div>

> "Hang in there, this platform is just a baby right now, but it's growing quickly! Keep in mind the Spark Team is still working hard to iron out some pretty critical bugs." - @timb

I know man, and I sincerely want you guys to know that I think we all appreciate it! If I was a more low level guy I would be more able to help at this point. Once we get a stronger IDE and the firmware is more stable, then I can do some very nice libraries for you all as payback 😄

Ken

---

<div class="post-metadata">

**Author:** ![mtnscott](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mtnscott/32/3217_2.png) [@mtnscott](https://community.particle.io/u/mtnscott)\
**Post date:** [January 23, 2014, 7:18pm UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/15 "2014-01-23T19:18:36Z")

</div>

> [@timb](#):
>
> That's on my, uh, "Personal Sprint" list. I'm systematically rewriting the entire I2C system to function with DMA and not perform any sort of blocking.

@timb How is this coming along? I have noticed some problems with reliability of the Serial and I2C communications. For example I notice that my Serial output seems to just go away after some time, the core continues to work (at least I think so, the cyan heartbeat is there). However, now that I have added code to support an I2C device (BMP085) The system seems to block on an I2C read pretty quickly.

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [January 23, 2014, 7:22pm UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/16 "2014-01-23T19:22:10Z")

</div>

@mtnscott would you please share your code? Either in here or a link to [pastebin.com](http://pastebin.com) or [gist.github.com](http://gist.github.com) would be great.

---

<div class="post-metadata">

**Author:** ![mtnscott](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mtnscott/32/3217_2.png) [@mtnscott](https://community.particle.io/u/mtnscott)\
**Post date:** [January 23, 2014, 7:43pm UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/17 "2014-01-23T19:43:43Z")

</div>

> [@BDub](#):
>
> @mtnscott would you please share your code? Either in here or a link to [pastebin.com](http://pastebin.com) or [gist.github.com](http://gist.github.com) would be great.

Here is the location of my source -

> **[GitHub - mtnscott/I2C-BMP085-Example: Sample SPARK applicaton.cpp that uses...](https://github.com/mtnscott/I2C-BMP085-Example)**
>
> Sample SPARK applicaton.cpp that uses interrupts for DHT11, I2C for BMP085 - GitHub - mtnscott/I2C-BMP085-Example: Sample SPARK applicaton.cpp that uses interrupts for DHT11, I2C for BMP085

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [January 23, 2014, 7:51pm UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/18 "2014-01-23T19:51:38Z")

</div>

You are affected by the 7-bit I2C address bug. See my code here for a working BMP085 lib.

> <https://gist.github.com/technobly/8342329>

You might just need to change your BMP085 address to 0xEE

If you don’t have device communicating out there, your code hangs:

```
if (!bmp.begin()) {
    Serial.println("Could not find a valid BMP085 sensor, check wiring!");
    while (1) {}
  }

```

The addressing will be fixed soon though in the core firmware on the compile-server2 branch.

---

<div class="post-metadata">

**Author:** ![mtnscott](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mtnscott/32/3217_2.png) [@mtnscott](https://community.particle.io/u/mtnscott)\
**Post date:** [January 23, 2014, 8:13pm UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/19 "2014-01-23T20:13:36Z")

</div>

The device communicates properly, it is able to give me several readings and then blocks on a 2 byte I2C read. I have since protected the 2 byte read statement with while(Wire.available() \< 2) ; and it now seems to be working (at least for 16 mins).

BTW - are the Wire.beginTransmission and Wire.endTransmission necessary around the Wire.read statements?

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [January 23, 2014, 8:46pm UTC](https://community.particle.io/t/i2c-not-working-as-expected/1997/20 "2014-01-23T20:46:56Z")

</div>

So you are already using address 0xEE?

No you shouldn’t need to, just the setup with requestFrom();

Here’s an example:  
[http://arduino.cc/en/Reference/WireRead](http://arduino.cc/en/Reference/WireRead)

EDIT: Looking at my BMP085 lib vs. yours… I see my reads have beginTransmission() and endTransmission() wrapped around them… that’s an error in the original Adafruit library. I just ported it. That could actually cause some issues I think.

[Next page](https://community.particle.io/t/i2c-not-working-as-expected/1997.md?page=2)