RTEMS | arm/stm32f4: Fix I2C mutex initialization and potential mutex leak (!1142)

[Mohamed Ayman (@mohamedayman23)]

Mohamed Ayman created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1142

Project:Branches: mohamedayman23/rtems:fix-some-possible-bugs-stm32f4-i2c to rtems/rtos/rtems:main
Author:   Mohamed Ayman



## Summary

arm/stm32f4: Fix I2C mutex initialization and potential mutex leak

Fix two issues in the STM32F4 I2C driver related to mutex handling. 

The mutex protecting the I2C bus was created with an initial count of 0. For a binary semaphore used as a mutex this causes the first rtems_semaphore_obtain() call to block indefinitely since the semaphore starts in the locked state. Initialize the semaphore with a count of 1 so it starts unlocked. 

Additionally, stm32f4_i2c_process_message() could return early if the STOP bit was set in CR1 without releasing the mutex. This would leave the mutex locked and cause subsequent calls to deadlock. Release the mutex before returning in this case. 

Also cast dummy SR2 reads to (void) to make the intent explicit and avoid potential compiler warnings about statements with no effect.

AI usage: yes\
Prompt used: help me to analyze this code in details and tell me the flow it written by, and what section in the reference manual should i read before coding\
AI model: gemini pro\
How AI was used: to help me in understanding the coding mindset of this file

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1142
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260316/7f829679/attachment.htm>