cancel
Showing results for 
Search instead for 
Did you mean: 

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

TDJ
Senior III

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.

3 REPLIES 3
TDJ
Senior III
Bob S
Principal

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
Senior III

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