How to Migrate a Sensor? A Detailed Debugging Process for MIPI CMOS Cameras

First, confirm whether the hardware interfaces of the motherboard and the module are consistent. Based on specific resolution, frame rate, and other requirements, obtain the corresponding register configuration from the module manufacturer, and configure the sensor driver and DTS according to the platform requirements. After completing the corresponding configuration, burn the firmware for testing. The migration process may encounter some issues, which are briefly introduced in two points below.

Generally, during the boot process, the camera driver framework will detect the sensor. If the corresponding hardware exists, a /dev/video node will be generated; if the detection is abnormal, there will be no corresponding node.

The detection process is generally done by the I2C driving the sensor’s chip ID, and the most common issue encountered during this process is I2C communication failure. If I2C communication fails, you can follow these steps for testing and confirmation:

1. First, confirm whether the I2C address of the sensor is configured correctly, as the I2C communication address is 7 bits, and different platforms may have some differences regarding this configuration. Some configure 7 bits; others configure 8 bits, with the last 1 bit being the read/write flag;

2. Confirm in the DTS whether the power, reset, pwdn, mclk, etc., of the module are configured correctly, including the connection of the LDO, voltage, pins, etc. (confirm with the schematic);

3. Confirm in the driver whether the power is configured according to the sensor datasheet during the power-up process and whether reset and pwdn are pulled to the appropriate level;

4. If at this step, I2C communication still fails, mask the sensor’s power-down function to keep the sensor powered on, and then use a multimeter to check whether the power supply voltage is correct, whether the reset and pwdn levels are normal, and whether mclk has output, and whether the I2C signal has pull-up;

5. If the power supply, reset, pwdn, mclk, and I2C are incorrect, then confirm the configuration of the driver and DTS, particularly paying attention to the amplitude of mclk, which should match IOVDD. If the amplitude of mclk is found to be very small, check the hardware or software configuration of the mclk pin;

6. During testing, if you suspect an issue with the hardware circuit or module, you can first remove the module and test the motherboard signals separately. Confirm that the signals are normal before connecting the module for measurement (in some cases, a short circuit may occur after connecting the module; this situation may indicate a problem with the module or the motherboard, and specific issues should be analyzed accordingly);

7. If the hardware signal measurement shows that the module’s power supply voltage is correct, and the reset, pwdn pin level states meet the datasheet requirements, and the mclk waveform is correct (pay attention to the amplitude), and I2C has normal pull-up, but I2C communication still fails, update the board and module for testing. Originally, this step could also be performed first, but I prefer to put it last, first suspecting myself before considering others;

8. If any signal meets the conditions but I2C communication still fails, confirm again whether the sensor I2C address is correct (you can use the i2c tools’ i2c detect command for device detection);

I2C communication is mostly related to hardware and configuration. By measuring step by step, troubleshooting can lead to normal communication. If it still doesn’t work, bring the hardware along to troubleshoot.

When I2C communication is normal, it means that the SOC can configure the sensor to output image data. This process often encounters situations where no image data can be received. Below is an analysis of the MIPI data reception issue:

1. First, measure and confirm whether the MIPI pins of the sensor have data output. If yes, it is normal; if not, confirm whether there are issues such as bad soldering or incorrect register configuration. Confirm with the module manufacturer whether the provided register configuration is correct and whether it can output images normally (this point I have also been misled on; after confirming that my measurement is correct, I have to dare to suspect);

2. In the sensor driver, confirm whether there is a certain delay after soft reset for the register configuration. Because the sensor needs a certain delay after reset before continuing to configure the registers, otherwise, there may be issues such as I2C communication failure or unsuccessful register writes.

3. Confirm whether the number of MIPI lanes output by the sensor register configuration is consistent with the hardware connections; inconsistencies can also lead to no data being received;

4. Use an oscilloscope to measure the MIPI signal to check whether the waveform is normal and meets the MIPI protocol requirements;

5. Confirm whether the SOC software is correct and whether the code has been modified;

This part is due to the fact that during the SOC MIPI reception process, it needs to detect the state transitions of each lane’s LP11-LP10-LP00 before switching to high-speed mode to prepare for reception. If the SOC enables the sensor output first and then configures the SOC MIPI, it may lead to the SOC MIPI controller waiting for the MIPI signal transition while the sensor has already started outputting.

This is also the reason I mentioned in the CSI MIPI signal analysis about configuring the sensor MIPI clock lane as a non-continuous clock mode to avoid the SOC missing the initial LP state transition and continuously failing to receive image data. After configuring it as a non-continuous clock mode, each frame of image data will have a complete LP state transition in the MIPI clock lane.

According to the MIPI CSI debugging introduction in the CSI MIPI signal analysis, modify the sensor’s MIPI registers to confirm whether it can receive images;

First, receive RAW data to exclude interference from other modules in the CSI pipeline;

After confirming that the software configuration is invalid, check whether the board has impedance matching (I have tried new boards that did not receive data; after reworking the board, confirming impedance matching, etc., the new board received normally), and check for bad soldering, short circuits on MIPI pins, etc. (often encountered with manual soldering);

There are not many things to rule out in MIPI reception; to summarize, confirm whether there are issues such as bad soldering or short circuits in the hardware, confirm that the software register configuration is correct and written, adjust the MIPI timing, and in the end, it will work out.

Source: MIPI Sensor Debugging Process_i2c Debugging Sensor – CSDN Blog

Excerpt from EEDesign WeChat Official Account