[v3.7] Writing extra device address byte using I2C on Ambiq Apollo3 EVB

[AleksSH97]

Hello,

I am currently implementing driver for SSD1315 OLED display controller and got confusing problem when my Ambiq Apollo3 EVB doesn't write right bytes into I2C (currently using display sample from Zephyr). I tried flashing display sample to nRF52833DK and it works perfectly. So I checked bytes with my logic analyzer and get following picture on Apollo3 EVB:

Then I checked same bytes on nRF52833DK:

I started investigating the problem in Zephyr's SSD1306 driver, in Zephyr's I2C implementation and Ambiq HAL's I2C implementation and found that Zephyr's i2c_burst_write() function prepares struct i2c_msg msg[2] array which contains msg[0] - start address of the command and msg[1] - buffer of our data. On the Ambiq's side. This means that Apollo3 writes msg[0] by writing I2C address of the device and data then msg[1] by writing the same I2C address and data.

As you can see Apollo3 EVB writes extra device address byte before command byte. I ended up writing some fixes into ssd1306.c from zephyr/drivers/display:

static inline int ssd1306_write_bus(const struct device *dev, uint8_t *buf, size_t len,
				    bool command)
{
	const struct ssd1306_config *config = dev->config;

	uint8_t final_buffer[len + 1];

	for (uint8_t idx = 0; idx < len; idx++) {
		final_buffer[idx + 1] = buf[idx];
	}

	final_buffer[0] = command ? SSD1306_CONTROL_ALL_BYTES_CMD : SSD1306_CONTROL_ALL_BYTES_DATA;

	return config->write_bus(dev, final_buffer, len + 1, command);
}

and into i2c.h from zephyr/include/zephyr/drivers

static inline int i2c_burst_write(const struct device *dev,
				  uint16_t dev_addr,
				  uint8_t start_addr,
				  const uint8_t *buf,
				  uint32_t num_bytes)
{
	struct i2c_msg msg[2];

	msg[0].buf = &start_addr;
	msg[0].len = 1U;
	msg[0].flags = I2C_MSG_WRITE;

	msg[1].buf = (uint8_t *)buf;
	msg[1].len = num_bytes;
	msg[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

	return i2c_transfer(dev, &msg[1], 1, dev_addr);
}

As you can see now SSD1306 driver makes one final buffer with control byte and then i2c_burst_write() writes only this new buffer.
I know that this is not a solution for Zephyr and it maybe needs to be fixed on the Ambiq HAL's side but I want to discuss this topic, maybe I'm losing some details.

Best regards

[ttmut]

Seems like I2C driver sends a STOP condition (orange squares on the logic analyzer output) after each msg, regardless of I2C_MSG_STOP being set or not. That's why every message starts with a new START condition and target address. In other words, the driver behaves as if the first message's flags are set like below.

	msg[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

[AleksSH97]

I agree but if we check i2c_ambiq_transfer() function:

static int i2c_ambiq_transfer(const struct device *dev, struct i2c_msg *msgs, uint8_t num_msgs,
			      uint16_t addr)
{
	struct i2c_ambiq_data *data = dev->data;
	int ret = 0;

	if (!num_msgs) {
		return 0;
	}

	/* Send out messages */
	k_sem_take(&data->bus_sem, K_FOREVER);

	for (int i = 0; i < num_msgs; i++) {
		if (msgs[i].flags & I2C_MSG_READ) {
			ret = i2c_ambiq_read(dev, &(msgs[i]), addr);
		} else {
			ret = i2c_ambiq_write(dev, &(msgs[i]), addr);
		}

		if (ret != 0) {
			k_sem_give(&data->bus_sem);
			return ret;
		}
	}

	k_sem_give(&data->bus_sem);

	return 0;
}

we can see that function writes struct i2c_msg *msgs instance by instance and Ambiq's HAL writes address of the device each call of the i2c_ambiq_write() function

To be more clear here Ambiq's HAL assigns device address inside am_hal_iom_blocking_transfer() function:
IOMn(ui32Module)->DEVCFG = psTransaction->uPeerInfo.ui32I2CDevAddr;

[ttmut]

That is also true.

There is a note in API docs that warns against such cases.

zephyr/include/zephyr/drivers/i2c.h

Lines 175 to 182 in 8f9148e

	* @note Some of the configurations supported by this API may not be
	* supported by specific SoC I2C hardware implementations, in
	* particular features related to bus transactions intended to read or
	* write data from different buffers within a single transaction.
	* Invocations of i2c_transfer() may not indicate an error when an
	* unsupported configuration is encountered. In some cases drivers
	* will generate separate transactions for each message fragment, with
	* or without presence of @ref I2C_MSG_RESTART in #flags.

[AleksSH97]

You are right, I missed that note, thank you!

So for this case I just included changed i2c.h header which works only for my project and only for one driver. I think this is the best way to handle this problem for now