Using digital oscilloscope to debug embedded I2C bus

This article explains the I2C communication problems encountered in actual development and how to use an oscilloscope to analyze and solve the problems.

The latest DS6104 oscilloscope launched by RIGOL was used in the analysis process. Its specific features include: up to 1GHz bandwidth, which is sufficient to meet the bandwidth requirements of commonly used standard buses; 5GSa/s real-time sampling rate to ensure that signal details are not missed; 180,000 waveform capture rates per second, with the highest probability of capturing signals of interest; standard 140M deep storage to meet the needs of both global overview and local observation; can record up to 180,000 frames of waveforms, and can replay and analyze strange signals at will; provides a variety of serial triggers, RS232, I2C, SPI, CAN, USB, etc.

Problem Discussion

The project design plans to use the Cypress 68013A chip to implement the USB device function. The 68013A is a high-speed USB device produced by Cypress. The reference design of this chip runs by reading the firmware program stored in the EEPROM through the I2C bus, as shown in Figure 1.

Figure 1: Schematic diagram of the connection between Cypress 68013A and EEPROM.

In order to further reduce the device area, power consumption, and facilitate the subsequent online firmware upgrade, it was decided to use DSP to simulate the communication between EEPROM and 68013A. At the same time, the firmware was downloaded to 68013A online through the I2C bus and run, as shown in Figure 2.

After programming with reference to the 68013A data sheet, I found that the firmware program could not be downloaded correctly when communicating with the 68013A through the DSP emulation EEPROM. That is, how can the DSP download the firmware to the 68013A through the I2C bus?

Figure 2: Schematic diagram of the connection between Cypress 68013A and DSP.

Workaround

First, you need to confirm that there are no problems with the communication environment, that is, there are no problems with the bus connection; there are no problems with the DSP's I2C communication program; there are no problems with the Cypress 68013A's I2C communication.

After verification, it was found that all the above items were correct, so the only possibility was that an error occurred during the communication process. However, no detailed description of the communication between 68013A and EEPROM was found in the reference manual. In order to obtain detailed data between the two in the initial communication stage, the DS6104 oscilloscope of RIGOL was used to capture the communication data in the initial stage.

The DS6104 oscilloscope has an I2C trigger and I2C decoding suite. To capture data, the following settings are required: Set the DS6104 oscilloscope trigger mode to "I2C" and the trigger condition to "start"; set the trigger clock source, data source and appropriate trigger level; turn on I2C decoding and set the decoding threshold; set the oscilloscope to single trigger. After the settings are completed, all communication data headers can be captured by monitoring the I2C communication with the EEPROM. Figure 3 shows the decoded data obtained.

Figure 3: Cypress 68013A and EEPROM I2C initial communication data.

By comparing with the firmware data read into the DSP memory (Figure 4), it can be seen that the "0xC2 0x47..." and subsequent data in the figure are the real firmware data. Therefore, the reason for the failure of DSP simulation EEPROM communication is the I2C communication from the start data to the firmware data (hereinafter referred to as handshake communication). After using the horizontal time base fine-tuning function of DS6104 to expand the waveform in the figure, the handshake communication process can be seen more clearly (Figure 5), which is described as follows: read address "0x50", no data is returned; read address "0x51", return "0xAD"; write address "0x51", write two bytes "0x00". [page]

Figure 4: 68013A firmware program data (partial) read into DSP memory.

At this point, the problem is simplified to: How to simulate this part of the handshake communication in DSP? After obtaining the visual handshake communication data through the oscilloscope, simulating its communication process only requires the following three steps: Set the I2C bus address of DSP to "0x51", and there will be no return if it does not match the address "0x50"; in the I2C communication program of DSP, send "0xAD" first when downloading the firmware, so that the first data read at the address "0x51" is "0xAD"; when DSP downloads the firmware through I2C, it can receive "0x00" but does not process it, to ensure the integrity of the handshake communication.

As mentioned above, after including this part of the handshake communication processing in the DSP's I2C communication program, the DSP emulated EEPROM and Cypress 68013A can communicate normally and successfully download the 68013A firmware.

Figure 5: Cypress 68013A and EEPROM I2C communication data header expansion.

The Cypress 68013A supports modifying the configuration word directly in the firmware (as shown in Figure 6, address 7), so that the boot type can be configured after the firmware is downloaded.

Figure 6: Cypress 68013A 'C2 Load' format.

We follow the register configuration format provided by the Cypress document as shown in Figure 7, configure the firmware to disconnect the USB connection at startup, and set the I2C clock to 400KHz (change the data at address 7 to "0x41"). [page]

Figure 7: Cypress 68013A firmware configuration word format.

Similarly, when downloading the firmware, you can use DS6104 to monitor the I2C communication data, and you can clearly see the change in clock frequency, as shown in Figure 8.

Figure 8: Changes in I2C communication data frequency when the firmware configuration word is “0x41”.

So far, we have used the DS6104 digital oscilloscope launched by RIGOL to realize the functions of DSP emulation EEPROM communication with Cypress 68013A and firmware download in a visual way. At the same time, during the firmware download process, we observed that the I2C communication frequency configured in the firmware can take effect immediately.

In the actual project, we also use I2C as the regular communication channel between DSP and 68013A. Obviously, in the subsequent debugging, the serial bus triggering and decoding provided by the DS6104 digital oscilloscope will also become our preferred debugging method.

Conclusion

The I2C bus has been widely used in embedded systems. In actual development, it is inevitable to encounter a lack of documentation. At this time, using an oscilloscope to debug as described in this article is a quick and effective method.

More and more buses are used in embedded systems, and the difficulty of development and debugging is also increasing accordingly. The DS6000 series oscilloscopes launched by RIGOL can effectively reduce the difficulty of embedded bus debugging and greatly improve debugging efficiency with its leading indicators, innovative technologies and various bus trigger and decoding kits.