Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HOTFIX:Backport of second round upstream NuttX i2c fix #6771

Merged
merged 1 commit into from
Mar 10, 2017

Conversation

davids5
Copy link
Member

@davids5 davids5 commented Mar 10, 2017

backport 3cd66af and pr 258

Applies to STM32F4 and STM32F7

STM32, STM32 F7, and STM32 L4: Clone Freddie Chopin's I2C change to similar STM32 I2C drivers.

Save elapsed time before handling I2C in stm32_i2c_sem_waitstop()
This patch follows the same logic as in previous fix to
stm32_i2c_sem_waitdone().
It is possible that a context switch occurs after I2C registers are read
but before elapsed time is saved in stm32_i2c_sem_waitstop(). It is then
possible that the registers were read only once with "elapsed time"
equal 0. When scheduler resumes this thread it is quite possible that
now "elapsed time" will be well above timeout threshold. In that case
the function returns and reports a timeout, even though the registers
were not read "recently".
Fix this by inverting the order of operations in the loop - save elapsed
time before reading registers. This way a context switch anywhere in the
loop will not cause an erroneous "timeout" error.

   backport 3cd66af and pr 258

   Applies to STM32F4 and STM32F7

   STM32, STM32 F7, and STM32 L4: Clone Freddie Chopin's I2C change to similar STM32 I2C drivers.

   Save elapsed time before handling I2C in stm32_i2c_sem_waitstop()
   This patch follows the same logic as in previous fix to
   stm32_i2c_sem_waitdone().
   It is possible that a context switch occurs after I2C registers are read
   but before elapsed time is saved in stm32_i2c_sem_waitstop(). It is then
   possible that the registers were read only once with "elapsed time"
   equal 0. When scheduler resumes this thread it is quite possible that
   now "elapsed time" will be well above timeout threshold. In that case
   the function returns and reports a timeout, even though the registers
   were not read "recently".
   Fix this by inverting the order of operations in the loop - save elapsed
   time before reading registers. This way a context switch anywhere in the
   loop will not cause an erroneous "timeout" error.
@davids5
Copy link
Member Author

davids5 commented Mar 10, 2017

@LorenzMeier - second set

@davids5 davids5 merged commit c967cad into master Mar 10, 2017
@LorenzMeier LorenzMeier deleted the master_i2c_fc2 branch March 13, 2017 20:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants