> For the complete documentation index, see [llms.txt](https://amobile-solutions.gitbook.io/yocto-developer-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://amobile-solutions.gitbook.io/yocto-developer-guide/test-and-use-the-interface/i2c/i2c-iot-800n-g420.md).

# I2C - IOT-800N-G420

## Bus map

| Bus  | Device                                           | Address |
| ---- | ------------------------------------------------ | ------- |
| i2c0 | BMI270 6-axis IMU                                | 0x69    |
| i2c1 | RT1715 Type-C PD controller                      | 0x4E    |
| i2c2 | MCP7940N RTC                                     | 0x6F    |
| i2c3 | (unused)                                         |         |
| i2c5 | ilitek TDDI v4 touch, behind a TCA9517A repeater | 0x41    |
| i2c7 | S5K3L6 camera sensor                             | 0x2D    |
| i2c7 | Camera EEPROM                                    | 0x50    |

{% hint style="warning" %}
i2c4, i2c6 and i2c8 are disabled in the device tree. On this carrier their pins carry other functions — i2c8's pins are the RS-232 and DIO supply enables, so enabling that bus would cut power to the DB9 port and the digital IO at the same time.
{% endhint %}

## Listing the buses

```
i2cdetect -l
```

```
ls /sys/bus/i2c/devices/
```

```
0-0069    BMI270
1-004e    RT1715
2-006f    MCP7940N
5-0041    ilitek
7-002d    S5K3L6
```

## Scanning a bus

```
i2cdetect -y -r 0
```

{% hint style="info" %}
Addresses already claimed by a driver are shown as `UU` rather than the address, so a device bound to its driver will not appear as a plain number. Unbind it first if the raw address is needed:

```
echo 0-0069 > /sys/bus/i2c/drivers/bmi270_i2c/unbind
i2cdetect -y -r 0
echo 0-0069 > /sys/bus/i2c/drivers/bmi270_i2c/bind
```

{% endhint %}

## Reading and writing registers

```
i2cget -y <bus> <address> <register>
i2cget -y 2 0x6f 0x00

i2cset -y <bus> <address> <register> <value>
```

```
i2cdump -y <bus> <address>
```

{% hint style="danger" %}
`i2cset` and `i2cdump` write to and read from live devices. Writing to the PMIC or the PD controller can make the board unbootable.
{% endhint %}

## Bus speed

Every bus on this board runs at 400 kHz, set in the device tree:

```
clock-frequency = <400000>;
```

## Pull-ups

{% hint style="warning" %}
Carrier revision **R02** removed the external pull-ups on i2c0. On sheet 13 the resistors for the BMI270, the ALS and the MC3416 are all marked NM, so the device tree has to enable the SoC's internal pull-ups with `bias-pull-up` on `i2c0_pins`.

R0.1 had 2.2K pull-ups to VIO18\_PMU and used `bias-disable`. Carrying that setting onto R02 leaves SDA and SCL floating.
{% endhint %}

The other buses have their pull-ups fitted and use `bias-disable`.

## Troubleshooting

### A device times out

```
bmi270_i2c 0-0069: error -ETIMEDOUT: Failed to read chip id
```

Check the bus is electrically alive before suspecting the device:

```
i2cdetect -y -r 0
```

A healthy bus completes the scan and prints all eight rows, whether or not it finds anything. **If `i2cdetect` aborts partway through, the bus itself is not working** — usually missing pull-ups or a pinmux problem — and a dead bus looks exactly like a missing part.

### Checking the supply

```
grep -iE "sensor|dio|rs232" /sys/kernel/debug/regulator/regulator_summary
```

### Pinmux

The sensor bus has two possible pin functions: MODE 1 routes it to the SCP, MODE 2 to the application processor. IoT Yocto drives it from the AP, so `FUNC_SCL0` and `FUNC_SDA0` are correct. Selecting the SCP function leaves the AP connected to a line with no signal on it.