Correctly Identifying Jetson Orin Nano I²C Buses & Using the ADXL345

Logical I²C Names vs. Linux Bus Numbers

NVIDIA Jetson documentation and many community posts refer to I²C interfaces using logical names such as:

• I2C1 → 40-pin header (pins 3: SDA, 5: SCL)
• I2C0 → camera / MIPI subsystem

These identifiers are useful at the schematic and device-tree level, but they do not guarantee a one-to-one match with Linux device nodes such as /dev/i2c-1, /dev/i2c-7, or /dev/i2c-8.

On Jetson platforms, the Linux kernel assigns I²C bus numbers based on the order in which the Tegra I²C controllers are registered. This ordering can vary with:

• JetPack / L4T version
• Kernel revisions
• Carrier board design
• Device-tree configuration and overlays

As a result, a 40-pin header bus that earlier guides call i2c-8 may appear as i2c-7 (or another index) on a different firmware or image. If a developer assumes the bus number from a tutorial instead of interrogating the system, the I²C header can appear to be “missing” even though it is fully functional.

Discovering Active I²C Controllers on Jetson

The most reliable way to understand how a specific Jetson installation is wired is to query the kernel for all active I²C adapters:

i2cdetect -l

Example output from a Jetson Orin Nano system:

i2c-0   i2c     3160000.i2c                      I2C adapter
i2c-1   i2c     c240000.i2c                      I2C adapter
i2c-2   i2c     3180000.i2c                      I2C adapter
i2c-4   i2c     Tegra BPMP I2C adapter           I2C adapter
i2c-5   i2c     31b0000.i2c                      I2C adapter
i2c-7   i2c     c250000.i2c                      I2C adapter
i2c-9   i2c     NVIDIA SOC i2c adapter 0         I2C adapter

Notice that there is no explicit mention of a “header bus” in this listing, and in this particular case there is no i2c-8 at all. The 40-pin header I²C signals are present electrically, but they are mapped to one of the listed buses (here, i2c-7) based on the underlying device-tree configuration.

Finding the Header Bus by Probing

A simple, repeatable way to locate a connected I²C sensor is to scan every bus reported by i2cdetect -l. The loop below queries each bus using read-based probing, which is generally safe and Jetson-friendly:

for bus in $(i2cdetect -l | awk '{print $1}' | sed 's/i2c-//'); do
    echo "=== Scanning bus $bus ==="
    sudo i2cdetect -y -r $bus
    echo ""
done

This approach avoids assumptions. The developer simply wires a known-good sensor to the header pins, runs the loop, and observes on which I²C bus the device responds.

Using the ADXL345 as a Practical Test Device

The ADXL345 is a widely available 3-axis MEMS accelerometer that communicates over I²C or SPI. On the I²C interface, it typically appears at:

• 0x53 when the ALT ADDRESS pin is tied high
• 0x1D when the ALT ADDRESS pin is tied low

4.1. Header Wiring (3.3 V Logic)

On the Jetson Orin Nano 40-pin header, a typical I²C connection for the ADXL345 is:

• Pin 1 → 3.3 V → ADXL345 VDD
• Pin 3 → SDA → ADXL345 SDA
• Pin 5 → SCL → ADXL345 SCL
• Pin 6 → GND → ADXL345 GND

The ADXL345 is a 3.3 V device and its I/O pins are not 5 V tolerant. Some breakout boards add on-board level shifting and regulators, but when in doubt, treating it as a 3.3 V-only device is the safest path on Jetson.

4.2. Detecting the ADXL345 on the Correct Bus

With the ADXL345 wired to the header and the scan loop executed, the Jetson returned the following output for bus 7:

sudo i2cdetect -y -r 7

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

The entry at 0x53 confirms that the ADXL345 is visible on /dev/i2c-7. In this environment, the header I²C is therefore mapped to bus 7, not 8.

4.3. Verifying Device Identity (DEVID Register)

To confirm the device is actually an ADXL345, the DEVID register (address 0x00) can be queried. ADXL345 devices always return 0xE5 at this location:

sudo i2cget -y 7 0x53 0x00
0xe5

This value is effectively the device’s fingerprint. Reading 0xe5 confirms both the correct bus and the correct sensor.

Putting the ADXL345 into Measurement Mode

Once the device is detected and identified, placing the ADXL345 into measurement mode provides a quick functional test of the data path. The POWER_CTL register at 0x2D controls the measurement state. Setting bit 3 (MEASURE) enables active sampling:

# Enable measurement mode
sudo i2cset -y 7 0x53 0x2D 0x08

Acceleration data is then read from the six data registers beginning at 0x32 (X0) through 0x37 (Z1). Each axis is a signed 16-bit value, and in full-resolution mode the scale factor is approximately 3.9 mg/LSB:

# Example: reading X0..Z1 as a quick check
sudo i2cget -y 7 0x53 0x32
sudo i2cget -y 7 0x53 0x33
sudo i2cget -y 7 0x53 0x34
sudo i2cget -y 7 0x53 0x35
sudo i2cget -y 7 0x53 0x36
sudo i2cget -y 7 0x53 0x37

With even a simple script, these raw values can be scaled into g-units and fed into more advanced visualizations (for example, a Tkinter-based HMI dashboard or a streaming data logger for vibration and machine-health analysis).

Practical Guidelines for Jetson I²C Work

Understanding the distinction between logical I²C naming and runtime Linux bus numbering removes a common source of friction in embedded development on Jetson platforms. Rather than relying on static assumptions from older guides, developers can use a short, repeatable discovery process to identify the correct bus and verify sensor connectivity with confidence.