I2C is popular because many sensors, displays, real-time clocks, ADCs, DACs and I/O expanders can share the same two signal wires: SDA and SCL. This makes wiring much cleaner than using a separate set of pins for every module.
But I2C has one important rule: each device on the same bus must have its own address. If two modules use the same I2C address, the microcontroller cannot talk to them separately.
This problem often appears when a project works with one module, but fails as soon as a second similar module is connected.
Typical Symptoms
- One I2C module works alone, but two together do not work.
- The I2C scanner shows only one address even though two modules are connected.
- Two identical sensors always return the same reading.
- A display stops working when another module is added.
- Sensor readings become random or impossible.
- A library finds a device, but talks to the wrong one.
- The I2C bus locks up when both modules are connected.
Why I2C Address Conflicts Happen
Each I2C device listens for its own address. When the microcontroller sends that address, the matching device responds.
If two devices have the same address, they both respond at the same time. The microcontroller has no way to know which one is answering. Even worse, both devices may try to send data at the same time.
This can cause wrong readings, failed communication, or a completely confused I2C bus.
The I2C Scanner Cannot Always Warn You
An I2C scanner reports which addresses respond. If two devices share the same address, the scanner may still show only one address.
For example, if two modules both use 0x48, the scanner will usually report:
I2C device found at 0x48
That does not mean there is only one device. It only means at least one device answered at that address.
This is why address conflicts are easy to miss.
Common Modules That Can Conflict
Address conflicts are especially common when using two or more identical modules.
| Module Type | Common Address | Conflict Risk |
|---|---|---|
| SSD1306 / SH1106 OLED display | 0x3C or 0x3D | High when using multiple OLEDs |
| DS3231 / DS1307 RTC | 0x68 | High if using more than one RTC |
| ADS1115 ADC | 0x48 default | Medium; address pins often allow changes |
| MCP23017 I/O expander | 0x20 default | Low to medium; several address options available |
| PCF8574 I/O expander | Often 0x20 to 0x27 | Medium; depends on address jumpers |
| PCF8574A LCD backpack | Often 0x38 to 0x3F | Medium; similar backpacks may share address |
| BMP280 / BME280 | 0x76 or 0x77 | Medium; usually only two options |
| AHT20 | Often fixed at 0x38 | High when using multiple identical sensors |
Common Cause: Two Identical Sensors
The most obvious conflict happens when two identical modules are connected to the same I2C bus.
For example:
- Two identical temperature sensors.
- Two identical OLED displays.
- Two identical ADC modules.
- Two identical I/O expanders with the same jumper settings.
If the module has address jumpers, you may be able to change one module to another address. If the address is fixed, both modules cannot share the same bus directly.
Common Cause: Different Modules with the Same Address
An address conflict does not require identical modules. Two completely different modules can still use the same I2C address.
For example, one module may use address 0x38 for a sensor, while another module uses 0x38 for an I/O expander or LCD backpack variant.
The microcontroller does not know or care what kind of device is at the address. If two devices answer to the same address, there is a conflict.
Common Cause: Address Jumpers Not Set Correctly
Many I2C modules include solder jumpers or address pads. These are often labeled:
- A0
- A1
- A2
- ADDR
- AD0
- SA0
These jumpers may connect an address pin to GND or VCC. Changing the jumper changes the I2C address.
Problems happen when:
- Two modules are left at the factory default address.
- The jumper is not soldered cleanly.
- The documentation shows a different jumper layout than the actual module.
- The user changes the jumper but forgets to change the address in the sketch.
Common Cause: Library Assumes a Default Address
Even if you change the hardware address, the software must also use the new address.
For example, if an ADS1115 module is changed from 0x48 to 0x49, the library must be told to use 0x49.
ads.begin(0x49);
If the code still uses the default address, the library will keep talking to the wrong address or fail to find the device.
How to Find an Address Conflict
The best method is to test modules one at a time.
- Connect only the first I2C module.
- Run the I2C scanner and write down the address.
- Disconnect the first module.
- Connect only the second module.
- Run the scanner again and write down the address.
- If both modules use the same address, there is a conflict.
- Change one address if possible, or use a multiplexer.
Testing all modules together first can hide the problem because the scanner may only show one shared address.
Solution 1: Change the Address with Jumpers
If the module supports address selection, this is usually the easiest fix.
Common examples:
- ADS1115 can usually use several addresses depending on the ADDR pin.
- MCP23017 has three address pins and can support multiple devices on one bus.
- PCF8574 modules often have A0, A1 and A2 address jumpers.
- Some OLED displays allow switching between 0x3C and 0x3D.
After changing the jumper, run the I2C scanner again and update the sketch.
Solution 2: Use an I2C Multiplexer
If two modules have the same fixed address, an I2C multiplexer is often the clean solution.
An I2C multiplexer such as TCA9548A or TCA9546A connects several separate I2C channels to one controller. Devices with the same address can be placed on different channels.
The microcontroller selects one channel at a time, then talks to the device on that channel.
This is useful for:
- Multiple identical sensors with fixed addresses.
- Several identical OLED displays.
- Large projects with many I2C devices.
- Separating bus sections for easier troubleshooting.
Solution 3: Use a Second I2C Bus
Some microcontrollers can use more than one I2C bus. ESP32, RP2040 and some other modern controllers can often create a second I2C interface on different pins.
This allows one conflicting device on the first bus and another conflicting device on the second bus.
This can work well, but the code and libraries must support using different I2C bus objects.
Solution 4: Use a Different Module Variant
Sometimes the easiest solution is to use a different module version with a different address or a different chip.
For example:
- Use a sensor module with selectable address.
- Use SPI version of a display instead of I2C.
- Use a different ADC with more address options.
- Use one larger I/O expander instead of several fixed-address devices.
This is especially useful when designing a product or kit, where repeatability matters.
Solution 5: Do Not Use Two of the Same Fixed-Address Module
Sometimes there is no clean direct fix. If a module has a fixed address and the library does not support multiple buses or multiplexers easily, avoid using two of that module on the same bus.
For a quick hobby project, replacing one module may be faster than fighting the address conflict.
Address Conflicts vs Pull-Up Problems
Address conflicts and pull-up problems can look similar because both can make I2C unreliable.
| Problem | Typical Clue | Best Test |
|---|---|---|
| Address conflict | Two modules work alone but not together | Scan each module separately and compare addresses |
| Missing pull-ups | Scanner finds nothing or bus is unstable | Measure idle voltage on SDA/SCL and add proper pull-ups |
| Too many pull-ups | Works with few modules, fails with many modules | Check combined pull-up resistance |
| Bus too long | Works with short wires, fails with long wires | Shorten wires or lower I2C speed |
Do Not Guess the Address from the Product Name
Product descriptions are not always reliable. A module sold under the same name may use a different chip, different address jumper setting or different PCB revision.
Always run an I2C scanner on the actual module you are using.
This is especially important when buying low-cost modules from different suppliers or when mixing older and newer stock.
Recommended Troubleshooting Steps
- Connect only one I2C module.
- Run the I2C scanner and write down the address.
- Repeat for every module separately.
- Look for duplicate addresses.
- Check whether the conflicting modules have address jumpers.
- Change one address if possible.
- Update the address in the sketch or library initialization.
- If the address cannot be changed, use an I2C multiplexer.
- After fixing the conflict, test the modules together.
- If problems remain, check pull-ups, wiring length and voltage levels.
Quick Diagnostic Table
| Symptom | Likely Cause | First Thing to Try |
|---|---|---|
| Two identical sensors work alone, fail together | Same I2C address | Scan each sensor separately |
| Scanner shows one address for two modules | Both modules may share address | Disconnect and scan one at a time |
| Changed address jumper, code still fails | Sketch still uses old address | Update library begin address |
| Fixed-address modules cannot be used together | No alternate address available | Use TCA9548A/TCA9546A multiplexer |
| Many modules fail after adding one more | Address conflict or pull-up issue | Scan separately and check pull-ups |
CANABLOX Practical Note
CANABLOX is designed around modular I2C building blocks, so address planning is important. A modular system makes troubleshooting much easier because modules can be added one at a time and scanned after each change.
When combining CANABLOX modules, run an I2C scanner after adding every new module. If two useful modules ever need the same fixed address, an I2C multiplexer module or a second I2C bus can solve the problem cleanly.
Conclusion
I2C address conflicts are easy to overlook because an I2C scanner may still show an address even when two devices are answering at the same time.
If two modules work alone but fail together, test each one separately and compare their addresses. If the addresses are the same, change one address with jumpers if possible, use another I2C bus, or add an I2C multiplexer.
I2C is very reliable when every device has a unique address, proper pull-ups and clean wiring. Address planning is one of the keys to building larger Arduino, ESP32 and CANABLOX projects without random communication problems.