How to debug I2C devices in Proteus 6.9

When I first started debugging the connection between the TWI bus and AT24C02, I took a few days of detours because it was my first time to implement I2C in hardware. Today, I have completely debugged it. I will write down some debugging experience to save others from taking the same detours in the future.

It can be said that it is very convenient to debug I2C using Proteus. For example, after connecting MEGA8 and AT24C02 on the drawing, if you want to see the I2C debugging status, you can use two methods:

The first method is to connect an I2C Debugger instrument to the I2C bus. During the simulation debugging period, the instrument can display the I2C data transmission time, S (START state), Sr (ReStart state), A (Ask response), N (No ask state), P (Stop state), data (displaying the hexadecimal value of the data and the value of each bit at the same time). By checking the display of the I2C Debugger window, you can know whether the data sent and received on the I2C bus is correct.

The second method is to use the Log function in the property settings of the 24C series I2C EEPROM components. These Log functions are No by default, that is, not used. We can set it to Yes. One point in particular: the last item of these Log functions is Log to main Simulation Log, that is, whether to write the recorded situation to the main window simulation Log file. If you want to see the Log situation, this option must be selected Yes, otherwise you will not see the historical records. If the 24C series components receive or send flag information and data information, these information records can be seen in the Log file of the main window. The specific way to view it is to click Text Viewer in the System menu.

Let's talk about some debugging features of 24c series components in Proteus.

Once the data is correctly written to a certain address of the 24c series component placed in the schematic, the data will remain regardless of whether the debugging is stopped or the data file is reloaded or the schematic is reloaded. It's amazing, right? I found this problem in Proteus 6.9sp4, and this situation is completely different from what we imagined.

In addition, the reading and writing of 24c02 components must be performed in the following manner:

Read. AVR must send the START bit first, and then check whether the bus is under control. In many cases, TWI_STATUS returns TW_START, TW_REP_START, or can continue to transmit. Next, send [address|TW_WRITE], then check TWI_STATUS. If correct, it should return TW_MT_SLA_ACK, and then you can send the address byte. If the transmission is successful, TWI_STATUS returns TW_MT_DATA_ACK, and then you can continue to send the START bit, [address|TW_READ], and then AVR automatically switches to the host read state. After waiting for a while, if something is read, you can detect TW_MR_DATA_ACK or TW_MR_DATA_NACK in TWI_STATUS, and the data obtained in TWDR is the read data.

It is worth noting that in Proteus simulation, the response is very slow, and often TWI_STATUS will get TW_NO_INFO (no information). This happens because after the AVR receives the response signal, it takes a while for the value in TWI_STATUS to be updated. In order to read the correct data, you can wait for dozens of microseconds after TWINT is set, and then you can get the correct TWI_STATUS value.

The reason is that when data is sent or received, TWINT is set, but it takes some time to receive ACK/NACK, so it takes some time to receive the correct TWI_STATUS value. I have been struggling with this problem for a long time, and it is different from what I imagined, and the MEGA8 manual does not mention this. Finally, after a long time of struggling, I suddenly got an idea and figured it out.

I wrote this article to share with you.