I2C: Master Receiver PEC

[budde2]

Posted on October 30, 2008 at 07:34

I2C: Master Receiver PEC

[budde2]

Posted on May 17, 2011 at 12:49

Hi,

I am writing some code to implement the SMBus transfer types ''Send/Receive Byte'' and ''Block Write/Read''. I want to use the Packet Error Checking (PEC) feature of the SMBus. I have managed to implement the master transmitter messages (Send Byte, Block Write), but I have problems to implement the receiver messages (Receive Byte, Block Read). The STM32 reference manual is not a big help. It is missing something like the ''Figure 235. Transfer sequence diagram for master receiver'' when using PEC. At the moment I have the problem the both the last data byte and the PEC byte get not acknowledged. Or the I2C core reads an additional ''0xFF'' byte after the PEC byte. My code, which is called after reading the last real data byte and before sending the STOP condition looks like this:

Code:

void I2cMaster::ReceivePec() { I2C_AcknowledgeConfig(m_i2c, DISABLE); I2C_TransmitPEC(m_i2c, ENABLE); try { // while(I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED) != SUCCESS) CheckFlags(); } catch (...) { I2C_AcknowledgeConfig(m_i2c, ENABLE); throw; } I2C_AcknowledgeConfig(m_i2c, ENABLE); } What is the correct way to implement PEC?

[brianforde9]

Posted on May 17, 2011 at 12:49

Is that code running from within an ISR???

I have Master Rx / Slave Tx with PEC working, but all relevant code is within an ISR. The PEC generation (Master) is by software, not hardware. Similarly, I don't use the PEC hardware to determine if ACK/NAK should be sent. That is pre-determined (the last byte, the PEC, must me NAKed, always). The Master can use software the determine if the packet is good, and get again if necessary. The hardware PEC is only useful on the Slave Rx side. I only use the PEC hardware (on Slave Rx side) to determine if the PEC is correct, in order to generate ACK/NAK as appropriate for the received PEC. In that way, the Master Tx can know if the slave received the packet correctly, or not.