After the I2C READ command is sent, data is not synchronized immediately.

After the frequency of the DDR and arm changes, the I2C problem occurs again:

The previous processing logic is that when the sending buffer is empty, I will read the data in the receiving buffer, the result is determined based on the value of the data counter that reads the receiving buffer first after the interruption. The number of times the receiving FIFO is read is determined based on this value. The previous logic has always been good. This is based on the assumption that if the sending buffer is empty, all the commands required to be read have been successfully sent, in the receiving buffer FIFO, data consistent with the number of successful reads of the read command should be received, that is, each time I successfully send a read cmd, the received byte will surely exist in the receiving FIFO.

After changing the frequency, I found that when I pushed all the nine read commands into the sending buffer, when the sending buffer is empty, I read the counter that received the FIFO, and its value is 8. This clearly causes me to lose a piece of data. In this case, the previous assumption is wrong, that is, sending and receiving are not synchronous. After a READ command is sent, the receiving buffer receives data later. Therefore, the driver logic needs to be changed accordingly.

By the way:

When there is no new data in the receiving FIFO, you read it and always read the last data, that is, when the FIFO is empty, the last value is always left