I2C/SMBus, PEC register is not reset after RESTART condition - hardware bug suspected

[TDJ]

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:

• master requests 1 byte + PEC from slave, default addr 0x61
• slave transmits one byte (value 1) followed by PEC byte value 213
• master correctly NACKs, restarts, addresses slave and transmits 1 byte (value 1) + PEC byte (value 192)
• slave receives one byte (value 1) followed by correct PEC byte value 192
• PECERR error is raised at slave since the received PEC does not match PECR register content - PECR contains incorrect value 59

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.

[TDJ]

Other I2C hardware problems I described recently:

Missing I2C STOP condition

I2C master jams, unable to clear STOPF flag - probable hardware bug

[Bob S]

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.

[TDJ]

@Bob S​ True, but that is rather cheap excuse.