I2c does't work anymore

Is it possible that something went wrong and i2c doesn’t work anymore?

Is there any way to troubleshoot it?

I have a circuit with an external sensor that stop working, I’ve tried changing the sensor but nothing, then I’ve checked the sensor with an Arduino and it works, found at address 0x76 (as was supposed to be).

Then I tried with another Electron and same sensor, same circuit and it works.

With the broken one I’ve tried also to connect SCL/SDA to C4/C5 pins but it doesn’t work as well.

Any suggestion?

Mentioning a firmware version, and showing the code you’re using might be beneficial here…

Firmware is 0.7.0, full code si 700row… but let’s say that this normally show the address of the connected i2c sensor:

void i2cScan() {
    int address = 0;
    Adafruit_BME280 bme;
    for(address = 1; address < 127; address++ ) {
        if (bme.begin(address)) {
            String result = "Found sensor at address: 0x" + String(address,HEX);
            Particle.publish("i2c?", result);
    Particle.publish("i2c?", "end i2c scan");

How have you initialised the bme object?
By default it would use the Wire object connected to D0/D1 not C4/C5.

C4/C5 are referenced via Wire1

If you run into I2C issues you should try an raw I2C scan (cutting out any extra library).

Testing with an Arduino isn’t always a good test, since I2C on them doesn’t require extra pull-up resistors on Particle devices it does (if they are not on the sonsor board already).

I’d also not instantiate a temporary bme object but rather have it global.

Everything is connected with D0/D1, the software is working, I’ve 7 devices installed for months with the same hardware/software but now I have a faulty Electron (just one) that won’t communicate with i2c.

I’ll try the raw i2c scan. If I change




can I test C4/C5?

1 Like

You’d need ot substitute all references to Wire with Wire1 for that test.
Unfortunately none of the contributed BME280 libraries seem to support the alternative I2C interface. If you needed to switch to Wire1 you’d have to copy the library sources into your project and replace all instances of Wire.

I meant using the suggested raw I2C scan.

What’s next step if I found C4/C5 working? Is there any way to get back I2C communication on the standard pins?

That depends on the reason for them stopping to work in the first place. If the GPIOs got blown in any way then not.
In order to check that, you can use the input/output capabilities of the GPIO in standard pinMode()s


Hi @not103

Do you have long wiring for your i2c device(s)? That can cause problems.

If there any way static electricity could have zapped an open wire or connection?

Recent lightning storm in the area before they died?

Accidentally connecting with a higher voltage power supply?

These are the usual reasons GPIOs get blown.

As @ScruffR said another really good test is to write one-time testing firmware that uses these pins with regular digitalRead and digitalWrite to see if they work at all.


1.5 meter cable.
About static electricity / storm I don’t know.

Higher voltage not possible.

I performed this test: flashed the tinker connected the provided led and resistor first in D0 then in D1, result:

D0: with pin HIGH the led is on with full power, with pin LOW the led is on with "half power"
D1: with pin HIGH the led is on with full power, with pin LOW the led is off

tryed on D4 that’s not used at all on my code and it act like D1.

Is D0 died?

That does in deed sound like a dead pin.

With long wires like that you want to consider EM induced voltages and protect against it.


Most likely a walk-up zapping!

50cm is still considered as “long”? How I can protect it against EMI? Shielded cable (ie. cat5)?

I think I’ve just got another issue during last night storm… :frowning:

Shielded cables are a start.
But more effective would be GPIO protection circuits like Zener or clamping diodes or even more elaborate setups like outlined here

If you want to learn more about the topic, there are tons of resources online which can be found with search terms like GPIO protection

1 Like