CCI i2c clock frequency control

Products Support DragonBoard 820c
#1

Hello, I am using the db820c with some OV5645 image sensors. I was hoping to be able to reduce the i2c clock frequency to below standard (~50 kHz rather than 100 kHz). Would this be possible? I’ve attempted changing the device tree source in kernel/arch/arm64/boot/dts/qcom/msm8996.dtsi by adding a clock-frequency = <50000>; to the i2c stuff.

Is there a way to reduce the i2c for the cameras to below 100 kHz? The reason I am trying to do this is to allow the image sensor cable to be farther from the db820c.

Thanks

#2

You can try to modify the driver (drivers/i2c/i2c-qcom.cci.c) and update the 820c hw_param structure (hw_params_v1_4_0), baiscalyy try to double thigh and tlow.

#3

I suspect that the mipi lines will be more of a barrier to a working image sensor on a long wire than the i2c.

In the past I have found it necessary to run a 4 foot long ribbon wire to a camera, and I accomplished this by shielding the ribbon. I did this by wrapping the ribbon wire with aluminum duct tape, and of course connecting the tape electrically to GND.

#4

Hi @BScaramella

I agree with @doitright the I2C is the least of your worries, once you can transport the MIPI signals, the I2C signals will be fine. The best cables are microcoax cables, but they are really expensive. I have had good luck with JAE JF08 series cables and have run MIPI-CSI at 1 meter.

Keep in mind the MIPI-CSI (and DSI) specifications are intended for running signals at low power over the very short distances inside a cell phone. You need really good signal integrity to get a 1GHz+ signal with only 100mV amplitude to run over any significant distance. Any cable that can run the MIPI signals will have no problem with a 100kHz signal with 1.8V of amplitude.

P.S. there are no “off the shelf” MIPI cables, and every camera module out there has a different pin-out, so no matter what you will need to design a PCB for each end of the cable. Whoever does your PCB design and will understand the MIPI layout rules and how to get a cable to work.

#5

From another thread he created, he is using this mezzanine; MIPI Adapter Mezzanine - 96Boards

Which means that he does have off the shelf options for wiring, including silly things like this; https://www.buyapi.ca/product/flex-cable-for-raspberry-pi-camera-2-meters/

#6

Thank you for the input on the MIPI signals. So far I have been able to get input from the sensor with a 30 cm length cable for the MIPI and I2C lines. When I extend that cable to 100 cm, the sensor never connects in the first place, and from what I can tell by probing the I2C lines, it is because the image sensor drives the acknowledgment bit on SDA too slowly (the expected acknowledgment bit from the image sensor shows up one clock cycle late).

While I don’t know if MIPI will work that well over the one meter distance, I am planning on taking steps to increase signal integrity. However, unless I can overcome the I2C issues, I won’t know if MIPI might work as is.

Although I haven’t had any success with reducing the I2C clock at this point, I was thinking of other solutions as well. One idea was to use an I2C accelerator (here) that could drive the I2C line faster.
Another idea is to reduce the pull-up resistance of the I2C lines, allowing the ack bit to hopefully be sent sooner.

#7

On I2C bus a successful ACK is a LOW bit (not high), hence lower pullup resistor values, or an active pull-up won’t help. Are you sure the ACK is one clock cycle late? SDA should be low during SCL 9

image

Putting pullups at each end of the I2C lines often helps. (maybe 10K at each end)

#8

Whoops, I got that wrong, you are right.

Success_Short
Success_Short800×480 77 KB

Here is the SDA and SCL on a successful setup of a camera a short distance away on the I2C bus. (Measured near the db820c)
Failed_1m
Failed_1m800×480 73.4 KB

Here is the SDA and SCL on a failed setup of a camera on a 1m distance away on the same I2C bus. Again this was measured near the db820c.

It seems like in the first image, the slave acknowledgement comes before SDA rises. In the second, the slave acknowledgement is late, letting SDA stay high through the ninth clock pulse, and only being driven down after the ninth pulse.

This is why I expect that decreasing the I2C clock speed might sort out this issue.

#9

Looking at your scope traces, I would say you have multiple problems. The SCL signal looks really bad even at a short distance, but I think that is mostly how you have the scope setup and grounded.
A) Scope setup. you need to ‘compensate’ the scope probes to the scope. Basic concepts and instructions here: How to compensate oscilloscope probes or in your case on page 9 here: https://siglentna.com/USA_website_2014/Documents/UserManual/SDS2000_UserManual_UM01020-E03A.pdf

B) Each of the probes has a ground clip near the tip. you need to connect both clips to ground near where you are probing the signal. Without the local grounds your signals will look like what you have attached.

OK, after you compensate the probes go back and make 4 measurements

  1. Short cable with both probes grounded at the 820 and looking at the signals as close to the 820 as you can.
  2. repeat 1) with the long cables
  3. Short cable with both probes grounded as close to the camera as you can, and looking at the signals as close to the camera module as you can probe
  4. repeat 3) with the long cables.

The 4 images will tell us a lot more about the problem. I am pretty sure your problem is electrical in nature and caused by your wiring, but I am not sure yet. A picture of your setup and cables would also help.