Zephyr device tree and sensor with two I2C addresses

tedhavelka66

Good morning CircuitDojo Forum,

I’m working on an out-of-tree Zephyr device driver, and have a fair grasp of the Device Tree and DTS facets involved in drivers for Zephyr apps. I’ve recently learned that the accelerometer for which I’m developing a driver has potentially, effectively two I2C addresses. This is described in Kionix’s datasheet addendum:

https://kionixfs.azureedge.net/en/document/TN027-Power-On-Procedure.pdf

Device Tree’s paradigm sets I2C addresses in .dts and .overlay files at compile time. There does not appear to be a ready way to change a given sensor’s I2C address at run time, when it’s been associated in the device tree with a particular node there and fixed I2C address.

I am aware that there are some multi-sensor devices with two I2C addresses, allowing developers to address two different sensors in one physical package, which provides just a single wire pair for the I2C bus. Bosch’ BMI088 accelerometer plus gyroscope works this way. But in Kionix’ case the sensor is one and the same, and may power up with one of two addresses.

Is the best or only practical way to talk this sensor – in a Zephyr app context – to create a second Device Tree node with just the node label differentiated and the alternate I2C address? All other DTS node key value pairs held the same?

jaredwolff

tedhavelka66 you should tie the ADDR pin to a static source (either VDD or GND) that way it’s fixed for your application. I would not create two entries for the same device rather configure that address that works best with your application.

From the data sheet:

he Software Reset command may need to be sent to two I2C slave addresses. The 7-bit slave address associated with the KX132 and KX134 family of accelerometers is 00111YX, where the user programmable bit X, is determined by the assignment of ADDR (pin 1) to GND or IO_VDD

Hope that helps.

tedhavelka66

Hello Jared,

I have a breakout board for the KX132-1211 accelerometer, and this board ties the available ADDR pin of this sensor to IO_VDD. Therefore, that programmable (least significant) bit of the sensor’s I2C address is set. Kionix’ datasheet however describes the next least significant bit as one that’s “factory programmed” but apparently may lose its factory setting during an unstable power up. There is a page plus procedure outlined in the above datasheet to address this possibility.

Given this situation I believe my question is non-trivial, and goes to a seeming immutable nature of I2C addresses in Device Tree and Zephyr based device representations. I prefer not to create two entries in a device tree for one sensor, but I don’t see another way to handle this in Device Tree’s paradigm.

When you have the chance, let me know if you read that “TN Power Up” document differently.

jaredwolff

tedhavelka66 Ahh I get it now. Sorry I overlooked that section in the data sheet since it’s definitely… unconventional.

With that said, I think your intuition is correct with creating a different device tree entry. I looked around in the nrf_twi and abstracted i2c driver and there may be a way you can change the address on fly. Unsure without more research though.

tedhavelka66

Hello Jared,

Thank you much for looking into this. I realize you have a full time job, and maybe a second job like many, so I really appreciate your consistent and fast responses.

Not knowing much about Zephyr yet, but reviewing Zephyr’s I2C API I wondered whether there would be some way to craft an out-of-tree I2C driver or API for more or less just ‘write’ and ‘write_read’ functions. This, and still leverage those parts of Zephyr system configuration that device tree, Kconfig and the corresponding peripheral configuration before a given app starts running its main loop or thread like tasks. But it seems like that coding work would be pretty involved, and would deviate in many ways from Zephyr’s architecture and preferred conventions.

I’m getting a second device tree node in present Kionix work overlay file to compile, but I’ll need to connect an oscilloscope to the bus to convince myself fully that this idea will work or not. Will keep you posted on what I find - Ted