2023-03-12 08:17 AM
Synopsis: if controller (master) first receives data, after RESTART and direction change PEC register is not reset. As a result, PEC byte value calculated and sent by the controller after RESTART and direction change is based on the previous PEC value received from target (slave) and therefore incorrect. Problem does not occur in more typical scenario, when controller first transmits data and then receives.
Details: testing SMBus transition with STM32L432 I came across I2C interface hardware bug.
Test scenario:
After setting the START bit the initially transmitted PEC value 213 was not cleared and was used as the initial value after the restart. Calculations confirm that. That is, CRC8(213, 0x61<<1, 1)=59. The problem does not appear in a more typical scenario when master first transmits data and then receives after restart.
I found no workaround since PECR register cannot be cleared by software, it is read-only. No device errata seems be mention the described problem.
Please advise.
2023-06-05 08:28 AM
Other I2C hardware problems I described recently:
I2C master jams, unable to clear STOPF flag - probable hardware bug
2023-06-05 09:55 AM
The sequence you describe (master reads from slave then repeat start to write to slave) is not a valid SMBus transaction. As described in the SMBus spec, all "read from slave" operations end with a STOP.
2023-06-06 02:12 AM
@Bob S True, but that is rather cheap excuse.