I2C master read failure when 10-bit addressing is used with i2c_ll_stm32_v1

[AshwiniMShinde-eaton]

I am testing I2C master and slave example code using 10-bit addressing with STM32F429 target. The flow of I2C master example after initialization is as follows:
/* I2C single byte write */
struct i2c_msg msg;
int transfer_status;
msg.buf = write_buffer;
msg.len = length;
msg.flags = I2C_MSG_WRITE | I2C_MSG_STOP;
transfer_status = i2c_transfer( m_i2c_dev, &msg, no_of_msgs, slave_address );
if ( transfer_status != 0 )
{
LOG_ERR( "I2C - Failed to Write\n" );
}

k_msleep(1000);

/* Single byte read */
struct i2c_msg msg;
int transfer_status;
msg.buf = read_buffer;
msg.len = length;
msg.flags = I2C_MSG_READ | I2C_MSG_STOP;
transfer_status = i2c_transfer( m_i2c_dev, &msg, no_of_msgs, slave_address );
if ( transfer_status != 0 )
{
LOG_ERR( "I2C - Failed to Read\n" );
}

I observe that after single byte read is executed on master side, the slave example code gets stuck in "Write requested" callback as shown in the below screenshot
Logs and console output:

When I test the same slave example with I2C master simulator(Aardvark I2C adapter) then it works well. I believe the issue is with master i2c read or interrupts
Environment used:

• OS: Windows
• Toolchain Zephyr SDK

[erwango]

10 bit addressing not implemented on i2c_ii_stm32_v1.
Either we should return "not supported" or implement support

[FRASTM]

Is PR #51119 also fixing this issue ?

[AshwiniMShinde-eaton]

@FRASTM PR #51119 is fixing 10-bit addressing issue for stm32 hardware that uses i2c_ii_stm32_v2.cpp. The same changes will not work for i2c_ii_stm32_v1 because it seems that it will need additional changes which I am not aware of.

[FRASTM]

Did you try the same change as for i2c_V2:

		if (data->slave_cfg->flags == I2C_TARGET_FLAGS_ADDR_10_BITS)	{
			LL_I2C_SetOwnAddress1(i2c, config->address, LL_I2C_OWNADDRESS1_10BIT);
		} else {
			LL_I2C_SetOwnAddress1(i2c, config->address << 1U, LL_I2C_OWNADDRESS1_7BIT);
		}

[AshwiniMShinde-eaton]

Did you try the same change as for i2c_V2:

		if (data->slave_cfg->flags == I2C_TARGET_FLAGS_ADDR_10_BITS)	{
			LL_I2C_SetOwnAddress1(i2c, config->address, LL_I2C_OWNADDRESS1_10BIT);
		} else {
			LL_I2C_SetOwnAddress1(i2c, config->address << 1U, LL_I2C_OWNADDRESS1_7BIT);
		}

This change was for registering slave with 10-bit addressing. With this change, slave gets registered with 10-bit address in both i2c_ll_stm32_v1 and i2c_ll_stm32_v2 cases. But the issue that I reported here is with master that uses i2c_ll_stm32_v1

[erwango]

@AshwiniMShinde-eaton, Note that you're supposed to configure I2C_ADDR_10_BITS in the flags to get driver handle it. Did you had a try ?
Also, note that I2C 10 bit addressing is not complete in Zephyr I2C API: See #27670. Before completing implementation within specific drivers, the API part has to be completed.

[erwango]

I'm closing this point and expect the API to be completed before going further with driver implementation.

[AshwiniMShinde-eaton]

@AshwiniMShinde-eaton, Note that you're supposed to configure I2C_ADDR_10_BITS in the flags to get driver handle it. Did you had a try ? Also, note that I2C 10 bit addressing is not complete in Zephyr I2C API: See #27670. Before completing implementation within specific drivers, the API part has to be completed.

Yes I had set I2C_ADDR_10_BITS in the flags. This works for i2c_ll_stm32_v2 driver and I2C master is able to communicate using 10-bit addressing. I'm wondering why I2C master 10-bit addressing fails when using i2c_ll_stm32_v1 driver?

[ashutoshpandey-eaton]

10 bits addressing is working in i2c_ll_stm32_v2 driver but it is still not working in i2c_ll_stm32_v1 driver, please open this issue.

[AshwiniMShinde-eaton]

@erwango Please go through comment added by @ashutoshpandey-eaton and reopen this issue

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[ashutoshpandey-eaton]

I would like to have the label removed, as the issue is not fixed yet.