Just not working....

Hi,

If it is custom board, please refer application note for layout design Design Considerations for Connecting Analog Devices Video Decoders to MIPI CSI-2 Receivers

Please make sure whether you are using the correct I2C address.   

Have you verified with a scope the I2C timing and waveforms are correct?

Check to see if you can access anything else tied to the I2C bus, like eeprom.  Tie something to the bus to make sure the bus is working as expected.

Refer here EVAL-ADV7282A-M I2C detect not work - Q&A - Video - EngineerZone (analog.com)

Note: 

As per MIPI specification the MIPI receiver need to terminate the signals correctly. If the Microprocessor/ FPGA does not control the termination correctly then the MIPI signals from the ADV7282A cannot be decoded.

How do you configure the board either through script or through software driver?

Thanks,
Dharani S

Hi Dharani,

I have managed to configure RPi4 the way that I2C port 10 sends proper signals to camera connector. Checked with a scope. The thing is that the command

sudo i2cdetect -y 10 produces this table with numbers but no slave address is detected. The whole table is filled with "- -". So there is no communication with a chip. On this first prototype board I power all voltages at same time, also PWRDWN and RESET pins are pulled-up. The crystal oscillator is active and works.

I went through the link as above and I see that the guy had similar problem but there was no clue how to establish a communication with a chip.

Is it possible that this start-up sequence with RESET pin pulled down and up after powering device is so important and can open I2C port ?

Best regards

Jacek

OK, we have solved that. You should be able to open this pdf schematic.

brgds

Jacek

Hi,

As per the expert comment,

I noticed that on the customer’s board that the RESETN pin of ADV7282 is connected directly to +3.3 V.

Please ask the customer to try this experiment:  Disconnect RESETN from +3.3 V and then add an RC on the RESETN pin like what we do on our eval board.  The RC will delay the de-activation of RESETN until all supplies have come up and stabilized.  They could also add a pushbutton on RESETN to reset the device manually and see if that would resolve the I2C communication issue. 

Thanks,

Varshini K

Hi Varshini,

on my board it doesn't matter if RESET pin is high or low - the oscillator runs all the time. Maybe simply the chip is bad. I will check it.

So I have connected EVAL to RPi4. My observations :

- there is something wrong with initial RESET command 0x0F, 0x80. The chip doesn't reply with ACK so python module reports an error and stops. If I remove this command the whole script runs and EVAL board gives activity on MIPI output lines. If RESET is necessary I can do it later on in a hardware way. Observing I2C signals sent from EVAL it is the same (no proper ACK bit but EVAL ignores it) - maybe the chip starts reset action too early and there is no time for attaching ACK bit). I observe it very clearly on the oscilloscope.

But I would like to finally get any image on RPI4 from EVAL board. Some documentations say that ADV7282A-M is supported by RPi4 it is a matter to add a configuration line "dtoverlay=ADV7282M=1" in config.txt file. So I did but all known commands for opening a video window do not work.

So how to start this operation (in fact I have to make a stream with audio) ?

Regarding my custom board I will replace the chip and we will see.

brgds

Jacek

Hi,

I will try to add some lines to kernel, maybe finally this chip (EVAL board) will be seen by RPi.

But would be nice to have any reaction at least on my first question regarding RESET command, I am curious if there is a bug inside ADV chip. If this command is present the script stops. If removed the whole script is loaded, So RESET can be performed by hardware if necessary and then the whole script loaded.

thanks

Jacek

Hi,

    Kindly note that, If your first I2C transaction is a reset command (0x0F,0x80), the commands will also reset the I2C engine and subsequently fail the ACK response in the transaction So start with another command after power up/hardware reset.

 Could you please try the below sequence regarding RESET,

  As per recommended script, the normal sequence would be follow as like below, Please make sure with your i2c writes,

     delay 10;   // wait 10ms after hardware reset to start i2c
     42 0F 80;  // Reset Decoder (ADV7280A) - Chip reset for loading all I2c bits with default values (This bit is self clearing one, approximately it take 2ms for reset)
     delay 10;   // wait another 10ms
     42 0F 00;  // Exit power down mode [ADV7280A writes begin]

Note: Generally after ADV728x-M is programmed, the clock lanes should exit low power mode and it remains in high speed mode until the part is reset or powered down. In the ADV7280 rev.A datasheet the simplified power-up sequence state that a software reset is needed after power-up. After the hardware reset wait 10ms before beginning I2C communication. Not performing the hardware reset can leave the ADV7280 in a state where it is not able to perform I2C communication properly.

Please make sure with power sequence again - The PWRDN pin should be held low when the supplies are being brought up, and it should be brought up after the supplies are up and stable.

The RESET pin should be held low when the supplies are being brought up, and it should be released after a minimum of 5ms after the supplies and PWRDN pin are up and stable.

 Kindly refer this FAQ about crystal oscillation (+) How to Detect That the Crystal is Working Correctly on the ADV7182/ADV728x - Documents - Video - EngineerZone (analog.com)

Note that ADV7182, ADV7280, ADV7280-M, ADV7281, ADV7281-M, ADV7281-MA, ADV7282 or ADV7282-M system is first powered, you will find that the 28.63636MHz crystal will not oscillate. This is expected behavior as per design.

   Also Our older part like ADV7180 the crystal start oscillating immediately after power up. 

  (+) Explanation As To Why the Crystal Does Not Oscillate on ADV7182 or ADV728x Systems After Powerup - Documents - Video - EngineerZone (analog.com)

Thanks,

Poornima

Hi Poornima,

thank you for fast reply !

1. regarding I2C after reset it was my first idea that the chip resets itself and doesn't reply properly. BUT for I2C communication with available procedures (like with RPi4) it is not acceptable because the procedure reports an error and stops. So I prefer to make a hardware reset, wait required time and continue with the rest of commands.

2. looking at EVAL board schematic there is no special delay and sequence of power supply voltages. Only on RESET pin there is an RC network to make some delay. So should I understand that in fact RESET and PWRDN pins can be tied together and brought up together after required time ? Sounds logical.

3. the most interesting thing in my board is that by taking RESET pin down the oscillator doesn't stop. It runs all the time no matter what RESET pin level is. As I mentioned before maybe the chip is bad - I will check it later on. On EVAL board, yes, the oscillator stops after pressing RESET button and then starts after sending a script. As it should be.

At the moment I fight to achieve ANY image on RPi4 from EVAL board (here on signal lines I see activity after loading my script based on AD files).

kind regards

Jacek

Hi,

Could you please try with below experiment,

  1) Power up the chip as normal

  2) With a jumper wire or probe, pull the reset pin low to get a good solid hardware reset after power up.

  3) Try I2C transaction again.

Please note that, I2C bus is an open collector design and make sure the processor only pulls down the lines down, never drives them high.  Normally to do an I2C engines in FPGA or any processors you write a '0' to the output pin and then flip the pin direction.  When it's an output it pulls the bus low and when it's an input is allows the RC to pull the bus high.

Thanks,

Poornima

Hi,

all of the above was done before (I have mentioned about it). I2C doesn't work - I also have mentioned that this communication is established from RPi4. In communication with EVAL board it works as it should.

What's more after hardware reset the oscillator doesn't stop - it runs even during pulling RESET pin down !

I suspect that the chip is simply bad. I will make assembling of new chip on new PCB in professional oven. Then we will have a full picture.

Poornima, thanks so far for your assistance. Just give me some time for a/m actions and I will for sure come back to you with next results.

BTW, what should be current consumption from 1.8V line when oscillator is active ? I have 30mA, it seems to me a bit too low..

best regards

Jacek

Hi,

  Apologize for the delayed response since i am on leave.

    BTW, what should be current consumption from 1.8V line when oscillator is active ? I have 30mA, it seems to me a bit too low..

      Please refer below table from our schematic checklist, Here they have mentioned about how XTAL clock pins need to be connected when Crystal/Oscillator source is connected.

Also Kindly refer this pdf for "Crystal Design Considerations for Video Decoders, HDMI Receivers, and Transceiver" at 

PDF

Thanks,

Poornima

Hi Poornima,

I know very well this application note. My oscillator works at expected frequency. The thing is that when RESET pin is pulled down the oscillator still works (like RESET pin was inactive - maybe the chip is damaged we will check that but I wait for new PCB with some corrections).

I have asked about expected current consumption from 1.8V line. Could you check that please ?

BTW, are you leaving the company ? If yes will you pass my contact to another colleague who will take care about these threads further ?

Thanks and kind regards Jacek

Hi Poornima,

I know very well this application note. My oscillator works at expected frequency. The thing is that when RESET pin is pulled down the oscillator still works (like RESET pin was inactive - maybe the chip is damaged we will check that but I wait for new PCB with some corrections).

I have asked about expected current consumption from 1.8V line. Could you check that please ?

BTW, are you leaving the company ? If yes will you pass my contact to another colleague who will take care about these threads further ?

Thanks and kind regards Jacek

Hi,

  I have asked about expected current consumption from 1.8V line. Could you check that please?

    We don't have any specification regarding this current consumption. We will check with our expert team and get back to you.

    Meanwhile could you please check the same in our evaluation board. 

Thanks,

Poornima

Hi,

  Please find the below response from our expert regarding current consumption and RESET.

What should be current consumption from 1.8V line when oscillator is active ?

  The power consumption of the ADV7282 during normal operation is available in the data sheet.  If the customer wants to know what the power consumption of the chip is when the oscillator is active but there is no input signal, then I did not find any data available on that.  But the power consumption of the device in that mode is irrelevant because the 1.8V power supply has to be sized based on what the device requires during normal operation.

Regarding RESET Pin:

>> Irrespective of RESET pin (high or low) on customer board, the oscillator runs all the time  (Even taking the RESET pin down the oscillator doesn't stop. It runs all the time no matter what RESET pin level is).

It is possible this is just how the chip works.  That’s how the XTAL oscillator works on some of our HDMI devices as well – the XTAL oscillator will start oscillating once the power is applied to the device regardless of the status of the RESET pin.

Thanks,

Poornima

Hi Poornima,

Yes, the current consumption is specified in the datasheet (I looked at another document).

I have assembled another PCB (with some small corrections) and the chip was soldered in a professional way. The board has started to operate just with no other actions. But it behaves as I have expected : after power-up the chip is silent - current consumption close to 0 (maybe some uA but it is not important). The oscillator is stopped. When a proper script over I2C is passed to the chip the operation starts (current consumption from 1.8V circa 160mA). So it works on my custom PCB.

However I notice another phenomenon. During power-up the whole system I send some initial settings to the chip like PAL, contrast, brightness etc. Given 3 trials in one the brightness and contrast levels are completely out of order. Maybe the RPi4 procedure has bugs but my quick question here is : are there any special requirements in passing these parameters to the chip, time breaks between commands or whatsoever ?

thkx

Jacek

Hi,

are there any special requirements in passing these parameters to the chip, time breaks between commands or whatsoever ?

    No, It doesn't require any break between each command and just I2C configuration is enough.

In our chipset we will configure these color control register with default value (for example CONTRAST = 0x80, SATURATION = 0x80, BRIGHTNESS=0x00).

Also If you are facing any picture related issue, then configure Adaptive contrast enhancement (ACE). This block offers improved visual detail by using an algorithm to automatically vary the contrast levels to enhance picture detail.

The ACE function is disabled by default. Please refer Page49 for more details in http://www.analog.com/media/en/technical-documentation/user-guides/ADV7280_7281_7282_7283_UG-637.pdf

Thanks,

Poornima