[STM32F103] first I2C transaction always fails when PM_DEVICE_RUNTIME is enabled

[Oleh-Kravchenko]

Describe the bug
The first I2C transaction always fails when PM_DEVICE_RUNTIME is enabled on STM32F103.
I've stm32_min_dev_blue connected to the ssd1306 display.

To Reproduce
Steps to reproduce the behavior:

1. connect stm32_min_dev_blue to ssd1306;
2. enable CONFIG_PM=y, CONFIG_PM_DEVICE=y, CONFIG_PM_DEVICE_RUNTIME=y;
3. build and boot;

Expected behavior
ssd1306 should be initialized and ready to work.

Impact
Device driver error.

Logs and console output

D: stm32_i2c_msg_write: WRITE timeout
E: Failed to initialize device!
*** Booting Zephyr OS build zephyr-v3.3.0 ***
E: the device ssd1306@3c is not ready

Environment (please complete the following information):

• OS: Linux, MacOS
• Toolchain zephyr-sdk-0.15.2
• v3.3.0 (07c6af3)

Additional context
I've workaround the issue by adding a retry:

diff --git a/drivers/i2c/i2c_ll_stm32_v1.c b/drivers/i2c/i2c_ll_stm32_v1.c
index 9a64fc7fcc..0edc61ff45 100644
--- a/drivers/i2c/i2c_ll_stm32_v1.c
+++ b/drivers/i2c/i2c_ll_stm32_v1.c
@@ -617,7 +617,9 @@ int32_t stm32_i2c_msg_write(const struct device *dev, struct i2c_msg *msg,
 			    uint8_t *next_msg_flags, uint16_t saddr)
 {
 	struct i2c_stm32_data *data = dev->data;
+	bool first_fail = false;

+retry:
 	msg_init(dev, msg, next_msg_flags, saddr, I2C_REQUEST_WRITE);

 	stm32_i2c_enable_transfer_interrupts(dev);
@@ -626,6 +628,12 @@ int32_t stm32_i2c_msg_write(const struct device *dev, struct i2c_msg *msg,
 			K_MSEC(STM32_I2C_TRANSFER_TIMEOUT_MSEC)) != 0) {
 		LOG_DBG("%s: WRITE timeout", __func__);
 		stm32_i2c_reset(dev);
+
+		if (!first_fail) {
+			first_fail = true;
+			goto retry;
+		}
+
 		return -EIO;
 	}

[github-actions]

Hi @Oleh-Kravchenko! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[Oleh-Kravchenko]

I've grabbed I2C pins by Logic Analyzer, it looks like a trash:

[Oleh-Kravchenko]

Another workaround for the issue:

diff --git a/drivers/i2c/i2c_ll_stm32.c b/drivers/i2c/i2c_ll_stm32.c
index 74e1db91ce..9e7cb9a01a 100644
--- a/drivers/i2c/i2c_ll_stm32.c
+++ b/drivers/i2c/i2c_ll_stm32.c
@@ -250,14 +250,6 @@ static int i2c_stm32_suspend(const struct device *dev)
 {
 	int ret;
 	const struct i2c_stm32_config *cfg = dev->config;
-	const struct device *const clk = DEVICE_DT_GET(STM32_CLOCK_CONTROL_NODE);
-
-	/* Disable device clock. */
-	ret = clock_control_off(clk, (clock_control_subsys_t)&cfg->pclken[0]);
-	if (ret < 0) {
-		LOG_ERR("failure disabling I2C clock");
-		return ret;
-	}

 	/* Move pins to sleep state */
 	ret = pinctrl_apply_state(cfg->pcfg, PINCTRL_STATE_SLEEP);

[Oleh-Kravchenko]

Simular issues,

• STM32WL I2C doesn't work with LPM #37414
• stm32 sdmmc doesn't work correctly with power management enabled #53834

[erwango]

@Oleh-Kravchenko Can you have a look to #59200 ?

[knthm]

This is likely due to idle thread device resume logic and application-called driver logic fighting for the bus mutex.

See #60939 (comment)

[Oleh-Kravchenko]

@Oleh-Kravchenko Can you have a look to #59200 ?

Could you please be more specific?
Look for what exactly?

P.S.
I'm fresher in the Zephyr Project, so I don't understand your request.

[coran21]

I believe that this could be related to this issue / PR: #62988. Is that possible @Oleh-Kravchenko ?

[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.

[Oleh-Kravchenko]

Issue is still present