nrf91 i2c driver: Unexpected LOG_ERR when writing to an eeprom

[chrta]

Describe the bug

When writing to a eeprom that is connected via i2c, a error log message is printed.

To Reproduce

To reproduce the issue, i connected a EEPROM to I2C_2 and compiled the slightly modified hello_world sample, that adds I2C, EEPROM, shell and logger support.

I applied the following change to the hello_world sample:
lemonbeat@b97d89e

To build and flash the application:

cd samples/hello_world
west build -b nrf9160dk_nrf9160 --pristine
west flash

In the shell execute eeprom write and observer the log messages:

uart:~$ eeprom write EEPROM_0 0 1 2 3 4
Writing 4 bytes to EEPROM...
Verifying...
Verify OK

After a short delay, the log messages are printed:

[00:00:03.290,832] <err> i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0
[00:00:03.292,114] <err> i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0

The content is successfully written to the eeprom, but error messages are printed.

This does not happen on other platforms i use (STM32F4 and EFM32).
It looks similar to the issue fixed in #34388
Therefore i assume that this is an issue in the i2c_nrfx_twi.

Expected behavior

No error message is printed.

Impact

This is just an annoyance, since the data is successfully written into the eeprom.

Environment:

• OS: Ubuntu 20.04
• zephyr sdk 0.12.3
• current main branch d999d5e

[anangl]

This is not an issue in the i2s_nrfx_twim driver. It correctly reports that some I2C transactions failed (though, those messages could bring more useful information about the actual transactions; that's an improvement that could be done in the i2s_nrfx_twim). Right after issuing a successful write request, the shell command tries to verify the write. But during its internal write cycle, the EEPROM chip does not respond to any I2C transactions, so a few attempts in the following loop fail:

zephyr/drivers/eeprom/eeprom_at2x.c

Lines 264 to 278 in f6c338d

	/*
	* A write cycle may be in progress so reads must be attempted
	* until the current write cycle should be completed.
	*/
	timeout = k_uptime_get() + config->timeout;
	while (1) {
	int64_t now = k_uptime_get();
	err = i2c_write_read(data->bus_dev, bus_addr,
	addr, config->addr_width / 8,
	buf, len);
	if (!err || now > timeout) {
	break;
	}
	k_sleep(K_MSEC(1));
	}

[chrta]

Thank you for the information. This makes sense. If this is used by i2c peripheral drivers or application, maybe it is worth considering to lower the log level for this message, since this might be the intended behaviour?

I also see the error logs in "i2c scan" shell command for nearly every address (since there is no connected device with this address sending an ack). This is ok for me, but may trouble inexperienced shell users.

I change the type from bug to enhancement.

[mniestroj]

I have run into the same issue this week, when writing data from nRF5340 (via I2C_3 at TWIM) to EEPROM (AT24).