Closed etheory closed 2 years ago
I've since fixed this by switching to the HAL_I2C_EnableListen_IT, HAL_I2C_Slave_Seq_Receive_IT, HAL_I2C_Slave_Seq_Transmit_IT API's, which do not suffer from the above issue.
Hello,
This workaround seems correct and compliant with the SW design. But in your first comment on 5 July, did not find the Enable Listen IT notion.
So what is finally the workaround versus function call stack that you have done before ?
Regards
Describe the set-up
Describe the bug
I have a Nucleo G474RE driving the G0 via I2C. The exact same setup works perfectly when driving an Nucleo G431KB so it appears limited to the G0 series. When I perform the following sequence the first time, everything works:
Slave -> HAL_I2C_Slave_Receive_IT Master -> HAL_I2C_Master_Transmit_IT Slave -> HAL_I2C_SlaveRxCpltCallback -> HAL_I2C_Slave_Transmit_IT Master -> HAL_I2C_MasterTxCpltCallback -> HAL_I2C_Master_Receive_IT Slave -> HAL_I2C_SlaveTxCpltCallback -> HAL_I2C_Slave_Receive_IT And repeat....
On the first loop through, I am sending 1 byte from the master to the slave, then the slave responds with two bytes, and the first time, this works:
But the second time, the last byte fails to send:![image](https://user-images.githubusercontent.com/1401669/177362378-766df191-6658-4b7e-8f1b-935641a69f5d.png)
And the slave holds the clock low forever.
Inside the HAL driver:
On the second call of the sequence, it gets stuck forever, calling:
indefinitely.
The issue is that hi2c->XferCount and hi2c->XferSize are both zero, but tmpoptions is set to I2C_NO_OPTION_FRAME so it never completes. Also, TXIS and TXE are set to 1, so the transfer thinks it's incomplete, and continues to run indefinitely, holding the clock line low.
Additional context I have been unable to figure out the cause of this, but I've spent a LONG time looking in to it. It appears to be an issue with HAL.