You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When a transmit is attempted with fsl_i2c_cmsis.c I2C_Master_InterruptTransmit and the I2C bus is busy for reasons other than the master has not initiated a transaction, the master_handle.state gets stuck in busy without any way to recover. Calls to try to abort the transfer via I2C_InterruptControl are not successful because the check for being a Master transfer fails. Any subsequent transmit also returns busy due to only checking the master_handle.state and never going any lower to check if the bus is still busy.
To Reproduce
Environment:
Tag/Commit hash: generated from MCUXpresso SDK 2.4.2
Toolchain: arm-none-eabi-gcc-10.3.1
Board/SoC: MK24FN1M0xxx12
Steps to reproduce the behavior:
Initialize an instance of the CMSIS I2C driver (call Initialize, PowerControl(ARM_POWER_FULL), and Control to set the baud rate)
Trigger a stuck condition on the bus (we were able to by holding SDA low from a simulated slave)
Try to I2C_Master_InterruptTransmit (A repeated start condition happens and every subsequent transmit returns busy)
Expected behavior
The expectation is that if something happens that causes the I2C to become busy, that an abort or at the very least reinitializing the driver via PowerControl(ARM_POWER_OFF), Uninitialize, Initialize, and PowerControl(ARM_POWER_FULL) should reset the state of the driver to not busy (idle).
The text was updated successfully, but these errors were encountered:
Thanks for the feedback, did you still see the issue in our latest version of SDK? Already sent the issue to development, the feedback could be delayed, appreciate for your patience.
Describe the bug
When a transmit is attempted with fsl_i2c_cmsis.c I2C_Master_InterruptTransmit and the I2C bus is busy for reasons other than the master has not initiated a transaction, the master_handle.state gets stuck in busy without any way to recover. Calls to try to abort the transfer via I2C_InterruptControl are not successful because the check for being a Master transfer fails. Any subsequent transmit also returns busy due to only checking the master_handle.state and never going any lower to check if the bus is still busy.
To Reproduce
Expected behavior
The expectation is that if something happens that causes the I2C to become busy, that an abort or at the very least reinitializing the driver via PowerControl(ARM_POWER_OFF), Uninitialize, Initialize, and PowerControl(ARM_POWER_FULL) should reset the state of the driver to not busy (idle).
The text was updated successfully, but these errors were encountered: