No video through ADV7180 on custom board connected to Apalis iMX6Q/Ixora

Technical Support
, , , ,
1

Hi,

I’m struggling to get video output from an analog camera connected to an ADV7180 chip on a custom board. When I connect the same camera directly to a tv, or to the ACM 1.1 board, then the picture comes through (albeit with some vertical scrolling).

This is using the Apalis_iMX6_LinuxImageV2.6 (7c83cef) base image, with a slight modification - I’ve altered the device tree to find the ADV7180 chip on I2C bus 3 register 20 (instead of register 21 as in the default settings). I noticed this was different as dmesg was saying it couldn’t find ADV7180 on register 21, and inspection of the I2C bus 3 showed a connection on register 20.

I’m following the steps on the ADC instructions web page, using the gst-launch command for the Apalis suggested there, but all I see is a blue background (very occasionally I will get what looks to be a feed from the camera, but it is very dark). My dmesg contains the lines:

adv7180 3-0020: no sensor pwdn pin available

and:

mxc_v4l2_master_attach: ipu0:/csi0 parallel attached adv7180:mxc_v4l2_cap0

which seems to indicate that the ADV7180 chip is being detected and that v4l2 has successfully attached to it. However, I’m still not seeing a feed when trying to connect to the stream with gstreamer.

Any suggestions or hints would be very appreciated, and please let me know of any additional information I can provide which may be of use.

Thanks!

2

Hi

The fact that you get a blue video points towards issues on the analog side.

The ADV7180 when not detecting/locking on an input signal falls back to a free-run mode outputting a blue screen by default.
You could verify by changing the free-fun color, e.g. by changing the CbCr values used from the default 0x7c to 0xc7 in the ADV (in my case: i2c bus 3, device 0x21, register 0xd):

i2cset -f 3 0x21 0x0d 0xc7

Assuming that this changes your video to something reddish you’re issues will likely be on the analogue side of things.

Max

3

Max,

A long delay in responding to this, apologies. I’ve been working on this again recently. In short, your suggestion to change the color verified that the free-run mode color could be altered.

However, in doing so I noticed that the I2C bus was very unreliable - I would often get read/write errors. Examining dmesg with the adv7180 driver in debug mode also regularly showed failure to read from and write to registers on the adv7180 chip. I was worried that the custom board I was using with the adv7180 chip was faulty somehow, so I shifted over to using the Toradex Analog Camera Module (v1.1A).

Apalis IMX6 + Ixora + ACM v1.1A

I get the same I2C errors when using the ACM with the Ixora. I have had to use jumper cables to map from the 24-pin ACM connector to the 20-pin X14 header on the Ixora. However, with only power, ground, and I2C connected I still see very unreliable I2C transfers. Tapping into the I2C lines with a logic analyzer, it looks like the I2C bus gets ‘stuck’ with SCA low, and this prevents any further data transfer until the chip is reset. I’m not an I2C expert, but possibly there is lost data during the transactions and this leads to the slave device holding the line low waiting for a send to finish?

One curious behavior I have noticed is that if I set register 0x03 to tristate the video output, effectively turning it off, the behavior is much more stable. Initially I thought this might be due to crosstalk, but now that there is no physical connection carrying video data I’m not so sure.

Worried that the homemade cable connecting the ACM and X14 on the Ixora was an issue, I have now tried using the ACM in combination with the Apalis Eval Board.

Apalis IMX6 + Eval Board + ACM v1.1A

The fresh Apalis module I initially plugged into the Ixora was loaded with a v2.4 BSP. This used gst-launch-0.10 and the video feed appeared flawlessly, first time. Encouraging!

On another Apalis I used a mostly vanilla install of the Apalis_iMX6_LinuxImageV2.6_20160826.tar.bz2 BSP. I made two modifications to this:

  1. To alter the device tree to enable the ADV7180 driver and disable all others
  2. To modify the ADV7180 driver to not write a value to register 0x00 (to enable full autodetect of format). This has worked to a degree on the custom board (format is mostly detected reliably, when the I2C works).

Sadly, this just results in a blue-screen and the format is not correctly detected. However, the I2C seems to be stable and remains read and write-able.

To summarise my questions:

  1. Can you think of a reason why I2C would be unstable when connecting either a custom board with ADV7180, or the ACM (configured for ADV7180), to the Ixora? Could this be solely down to wiring? Or could something else be interfering with the bus?
  2. Is there a reason why v2.4 with gst-launch-0.10 works on the eval board ‘out of the box’? I noted that register 0x00 had value 0x00 (full autodetect) in that configuration.

Any help you can provide would be greatly appreciated!

4

Hi

at 1.
The Ixora has shorter traces on the PCB, so I actually would expect the Ixora to have less issues than the Evaluation Board. Other than the PCB traces and the wiring I’d don’t expect different experiences with I2C.

at 2.
The driver for the ADV7180 is nearly identical between the two version. Specifically both try to write 0x03 to register 0x00. As only the high nibble is about video standard detection writting 0x03 is autodetect of the video standard. The low nibble is used to select the input channel.
What input pin of the ADV7180 are you using on your custom board?

I did have huge issues with I2C when bringing up the driver for the MAX9526 Video DAC. Also with having the I2C stuck with SDA at 0V.

That lead to the addition of an I2C recovery mechanism. Unfortunately it is only used
in the MAX9526 driver. You could try if a similar loops in the ADV7180 driver which try to recover and repeat the i2c transmission help.

Note that ADV7180 seems not to be ADV7180. The original Freescale ADV7180 driver wrote to register addresses which did not exist on our ACM’s ADV7180. This lead to issues with not working ADVs. So your custom board might be different as well. Have a look at the inital working commit for ADV7180.

Max

5

Max,

Thanks for the reply. The custom board is currently using AIN1 for input (and it’s a 32-pin ADV7180 just for your awareness).

When I connect the ACM to the Ixora with just the I2C pins (and pwr / gnd of course) I have reliable I2C, but as soon as I have all of the cam related pins connected my I2C connection effectively dies. This prevents the v4l2 components from detecting the video, and prevents further testing.

I will look at bringing the recovery mechanism into the ADV7180 driver and see if that makes a difference.

Will update later. Thanks for the suggestions!

6

Max,

I modified the ADV7180 driver to use the same recovery mechanism as the MAX9526 driver, adding the value checks and calls to the recovery methods in the I2C read / write calls.

I have had mixed results with the ACM - only once have I seen it working reliably and as expected. Many times I will see multiple failed writes and reads on the I2C bus when the driver is configuring the chip. These were often exceeding the 5 retry limit, and sometimes even 10 retires wasn’t enough. At other points the bus seemed so confused that the chip was not even correctly identified.

Even when the driver correctly programs the registers at configuration time, later attempts to access register values with v4l2 result in incorrect values for video format, and scrambled video display. We don’t see the smooth adaptation to resolution and display that occurs with the Eval + ACM + v2.4 combination.

This always seems to happen when I have the video pins connected - as I mentioned previously, if I connect I2C on it’s own then I rarely see any communications issues and the registers can be reliably accessed. Once the video is connected then reliability goes way down.

Have you encountered video interfering with the I2C and chip configuration before? Is there anything different on the pin-muxing for the default V2.6b2 Ixora (vs. the eval board with v2.4) configuration that might lead to additional noise on the bus?

I see similar issues with our custom board, but am focusing on the ACM + Ixora combination for now as it is the one that you may be able to reproduce. If there is any further information I can provide then please let me know. We were hoping to use these boards as a long-term solution for our product, but this is fast becoming a showstopper for us.

7

@max.tx,

I’ve been testing further, but with no concrete forward progress. I had a period where the ACM was working well with the Ixora and producing good video from the camera. However, on subsequent boots I2C3 was too ‘busy’ even to allow register 0x00 to be set to 0x03 - resulting in no video output. This is basing from the V2.6b2 BSP with modifications to the ADV7180 driver (adding the recovery mechanism from the MAX driver).

Have you had any luck with reproducing the issue? Do you have any suggestions for how to proceed?

8

It’s very likely the cause of the problem is due to interface on the I2C from the parallel camera signals, mostly caused by the shared analog & digital grounds which leads to conductive coupling.

The first suggestion is to make the cable between the carrier board & ACM as short as possible. Use of the jumper cables in your Ixora configuration is likely exacerbating the problem. In the case of your custom board, it would help to separate the grounds. The layout will be critical and be sure to place series resistors on the camera interface. You can increase the value of these resistors to further diminish interference, although it will come at the cost of video quality.

If you’d like to share your schematics with us, we may be able to comment further.