Fix STM32F7_I2C emulation in master mode to handle i2c stall workaround added to i2c_ll_stm32_v2.c Zephyr driver

[Kate-MIA]

We started seeing an issue with STM32 I2C emulation after having migrated our project to Zephyr 4.3.0.

As of Zephyr 4.3.0 zephyr/drivers/i2c/i2c_ll_stm32_v2.c driver handles a workaround for “Transmission stalled after first byte transfer" added into stm32_i2c_irq_xfer function:

The workaround fixes an issue with stalled transmission after first byte transfer that is observed for some series of STM32 devices. E.g. for STM32H7xx, errata (es0392-stm32h742xig-stm32h743xig-stm32h750xb-stm32h753xi-device-errata-stmicroelectronics.pdf) states the following for I2C bus:

Therefore using the latest Zephyr driver in STM32 I2C master mode the first data byte is pushed to TXDR register prior to transaction start (writing"START" bit to CR2 register). This is how the workaround applies.

Using Zephyr 4.3.0 and STM32F7_I2C.cs we always see TXIS interrupt firing too early that results in an assertion on MCU side for our emulation. The assertion never occurs if we use the same firmware on a real hardware.

The current update adds a copy of STM32F7_I2C.cs emulation driver. The copy is able to operate in master mode only: any data received before transaction start (masterMode = false) is considered to be a workaround action. Function SlaveTransmitDataWrite is never used here.

STM32F7_I2C_Master.cs driver can be used in cases we need Master only mode on the MCU side and use the I2C Zephyr driver (as of now) on the firmware side.

If someone may advise a more elegant solution that will help us extend functionality of existing STM32F7_I2C.cs emulation driver, that would be great. So far, we didn't find a reliable way for the emulation driver to get to know that the first byte pushed to TXDR before transaction belongs to Master (controller) mode sequence, not to Slave (Target) mode one.

[CLAassistant]

All committers have signed the CLA.