i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0

[geoffF]

I know this topic has been raised before in theses places but I have tried all they suggest.

 RE: i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0 

 i2c_nrfx_twi: Error 0x0BAE0001 occurred for message 0 

I have tried the code on multiple boards and all give the same repeated error when calling the API function eeprom_write once.  The eeprom in question is https://www.microchip.com/en-us/product/at24c02d.  The device tree entry is below.  I have also tried putting a bias-pull-up on the pin control as suggested in some places. I2C signals look fine, the ACK is there and eeprom_read works without any error.

Connect SDK 2.3.0 and now 2.4.1 in an effort to resolve the error, no luck.

&i2c1 {
	compatible = "nordic,nrf-twim";
	status = "okay";
	pinctrl-0 = <&i2c1_default>;
	pinctrl-1 = <&i2c1_sleep>;
	pinctrl-names = "default", "sleep";
	micro_eeprom: micro_eeprom@50 {
        compatible = "atmel,at24";
        reg = < 0x50 >;
		status = "okay";
		size = < 256 >;
		pagesize = < 8 >;
		address-width = < 8 >;
		timeout = < 10 >;
    };
};

i2c1_default: i2c1_default {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 22)>,
				<NRF_PSEL(TWIM_SCL, 0, 4)>;
		};
	};

	i2c1_sleep: i2c1_sleep {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 22)>,
				<NRF_PSEL(TWIM_SCL, 0, 4)>;
			low-power-enable;
		};
	};

[geoffF]

Also the write is performed successfully, despite the error. Guess that is expected as it is an ACK error only.

[geoffF]

Seems this is just the underlying driver in i2c_nrfx_twim.c not waiting the write timeout period before writing again? If I breakpoint at the bottom of i2c_nrfx_twim_transfer (where this error is generated) to allow a delay after each call it works without error. There is a rety for this purpose in the higher function eeprom_at24_write in eeprom_at2x.c which tries for the timeout defined in the device tree so is why does this error even print since the write eventually goes though?

Why does it i2c_nrfx_twim_transfer not return EBUSY rather than the log message and EIO? Does it not support ACK polling without that error message? See:  https://onlinedocs.microchip.com/pr/GUID-8B75A8E3-EAC8-47E4-B4E2-84DB84C60333-en-US-2/index.html?GUID-D2EBF17F-0AE2-4C1F-8FCD-1638100570B3

[Vidar Berg]

Hello,

The underlying nrfx driver lacks knowledge about the operations of the EEPROM device and the ACK polling implemented by the at24 device driver. The write function will simply return an error code to notify the device driver when a requested transfer fails (address NACK in this case). The ACK polling mechanism is implemented by repeatedly calling i2c_write() until it returns '0' or until the timeout occurs after 10 ms as you can see from the implementation here: [link].

geoffF said:

Why does it i2c_nrfx_twim_transfer not return EBUSY rather than the log message and EIO? Does it not support ACK polling without that error message?

The nrfx driver does not know why the device is not ACKing the address in this scenario.

Best regards,

Vidar

[geoffF]

Thanks you for replying.  Understood and syspected that was the case.  So would you say that the nrfx driver is not really compatible with how the at24 driver has been implemented? ie. there is not way to avoid the error messages? Shall probably have to write my own in that case. Nordic is so prolific within Zephyr community, figured it would always be a standard against which drivers were written.

[Vidar Berg]

The nrfx layer is implemented to conform to the generic Zephyr i2c API, and the ACK polling mechanism in the at24 driver also relies on the i2c write API to return an error code when the write isn't acknowledged. So I would say the driver is working correctly. But it would have been nice if these error messages were suppressed during the ACK polling. I think the only solution to really avoid this is to turn off logging from the nrfx module or remove the line where the message is being printed.