OV7620 image sensor interface with FPGA headache

Hello,

I am trying to use the OV7620 to get a RGB digital output using FPGA Spartan 2 (PEGASUS by Digilent)with the intention to display the image on a regular monitor. The default output of the OV7620 is YCrCb, interlace scan, and 16-bit. While what I need is an RGB, progressive scan, and 8-bit output.

I tried so hard to write into the OV7620 register to get the output I want but of no avail. First I thought it might be because the FPGA I/O operates at 3.3v but the Omnivision data sheets mention that the minimum high input to the I2C bus is only 3v, so it should not be a problem.

The SDA and SCL output from the FPGA into the camera pins observed using an oscilloscope shows no problem; it produced signals as specified in the OmniVision data sheets. But when connected to the camera, there is no acknowledge signal, only a small pull down signal whenever acknowledge is expected (only about .1v down from 3.3v high) which I assume is nothing. The first thing I want to do is to write register 13h with the value 21h using the slave and write ID 84h. If this were a success write, the PCLK should get doubled up to 26-27MHz, shouldn't it? But I don't see any effect on the PCLK frequency (still at 13MHz) after my register write sequences.

Any help greatly will be appreciated. I have been trying this and that for weeks without progress. Is my sensor burned or I miss something? The analog output is still working right now, so I assume the chip is still normal. I'll be glad to give more detail as needed if someone can offer any help.

Thanks in advance!

Dalle

Reply to
dalle002
Loading thread data ...

Sounds to me like two drives one high and one trying to go low.

You are driving the SDA line as open-drain/open-collector with EXTERNAL pull up resistor as per I2C spec?

How can you be sure the ACK/NACK is operating properly on the FPGA on its own as the initial address sequence on I2C relies on the OTHER end pulling ACK bit low to handshake the address as valid and answering.

If your ACK/NACK sequences are not working correctly, nothing will.

I suggest you check that you are driving the FPGA pin as open drain, as its drive may be stronger than the pull down on the camera.

See above, I doubt the sensor is burned.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

Hello,

Thank you for your immediate response! I tried to follow your instructions as I understand it. This is what I did.

On the Verilog code I set SDA as inout and assign it as 0(LOW) when 0 is sent, or z(High Impedance) whenever a HIGH is sent. In the XilinxPACE I/O pin assignments, the SDA termination is set as pullup. With this setting, the oscilloscope displayed a ramp (instead of a clean square wave) whenever a HIGH or a HiZ is expected, which only peaked to about 1v. I guess there is a capacitance introduced because of this setting? The camera still don't response with this signal for obvious reasons.

Then I tried to use the same design setting except instead of using the FPGA IOB pullup termination, I set it back to "keeper" and use an external resistor - I connect the SDA to a 5v source through a 300k resistor and observed the output on the scope. Still the same, except the ramp peaked to about 4v. Actually, before I put the 5v connection, I also set the SDA IO standard to LVTTL (in Xilinx PACE also), making it a 5v tolerant pin for safety. Still the camera did not response.

Which part did I do wrong this time? One thing to mention is that I kept the camera's oscillator intact, so it has its on clock running at 27MHz while my FPGA runs at 50MHz. But using I2C should not require the FPGA to synchronize to the camera does it? The SCL runs at 400kHz as specified in the data sheets.

Any more help will be really appreciated. I almost completely lost any ideas and hope trying to get this project going.

Reply to
dalle002

Have you looked at a "real-world" I2C schematic? Try a maximum of 4k7 pullups on both SDA and SCL...

I know nothing about FGPAs...

Geo

Reply to
Geo

Dalle,

According to the datasheet the SCCB serial interface is enabled only if pin SBB = 0.

HTH,

-- Georgi

Reply to
Georgi Beloev

I do not know the OV7620. However, here are my 2 cents...

1) As Geo pointed out, the pullup is way too weak. Same for the internal fpga one. Put a 4K7; even less, even 1K for lower voltages I/O, to really go to 400 Khz. LVTLL for FPGA should be ok, if it helps to sustain 5V. 2) If the FPGA is powered at 3.3V, and you pullup the I2C lines to 5V, check the "inrush" current to the FPGA pin. EVEN when you program the pin as Hi-Z, the internal ESD diode of the FPGA could clamp the lines to 3.3V minus a diode drop. This could be less than what the OV7620 needs. Check if there's a pin standard that disconnects the internal diode. Or put a low ohm series resistor between the pullup and the FPGA pin, or a schottky diode if you have enough voltage margin. 3) Just to be sure, initially lower the frequency. Until it works, make I2C run much lower, even at tens of Khz. So you can concentrate on logic issues. 4) Are you absolutely sure of the expected effect on the sensor of the values you're going to write ? Did you experiment with the sensor in a different board ? 5) Depending on 4), why not to hook up just the I2C lines and ground to any microcontroller or emulator you have ? Even a simple 8 pin PIC, or R8C Tiny, or whatever will do. Just to "play" with the sensor to know its quirks. 6) I don't know if this applies to you, but I have been burnt by a bug on Xilinx tools about bidirectional buses. Beware at using bidirectional "iobuf" instantiated on HDL modules (my was in VHDL), put on a schematic top level. The sch2vhdl translation will not work with older tools. This was on ISE 4.2. I then found also a "Answer" on xilinx site about this known bug. 7) You can also build a dirt cheap I2C adapter for LPT port; Google is your friend, you'll find many designs, some of them with software.

Just for my curiosity.... why did you say the sensor outputs interlaced signals ? Its datasheet says it's able to output also progressive scan video... (yes, maybe you would need to change its settings by I2C ;-)

Reply to
Antonio Pasini

As others have said check that the sensor has I2C enabled (I forgot that most need this enabled).

I NEVER trust any FPGA/PLD/CPLD implementation of opne drain unless it specifically STATES that the output is ACTUALLY open drain. So many times they have all sorts of weak-pullup (actually an active current source), diodes and other configurations that do not operate the same.

These HiZ and other pullup schemes can be anything between an effective

10K and 10M impedance and can in some cases vary between chip, temperature etc.

As others have said 4K7 is the max in I2C spec I regularly use 1K to 2K7 depending on cable lengths, speed, and loads.

300K is probably about the same as the high side impedance of the output buffer.

In all forms of I2C the clock rate 100KHz, 400KHz and higher speeds is the MAXIMUM for that form of I2C support you can run it as slow as you like.

Follwow what others have said check

1/ I2C is enabled on sensor

2/ Reduce your pullups to 1K and increas from there Change the output stage as suggested by others.

3/ Put a feed through resistor between pullup and FPGA pin.

4/ Try using a known working I2C master to test the sensor

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

Dear helpers,

Your inputs were awesome. I made sure the I2C was enabled, put a 4k7 pullup resistor and make sure the timing specifications are met and BAM! it works! I got the acknowledge signals and the PCLK frequency has doubled to 27MHZ. I was jumping up and down for a while in gladness. Thank you all for your help. Probably my biggest mistake is the 300k resistor I used.

Now I still need further help on sending the image to the VGA monitor. Did anyone has succesfully send the digital image directly to a monitor without any need of storing the image in a memory?

I tried to store the pixel information in registers that is output to the color signals to the monitor. I noticed with progressive 16-bit mode, the UV channel output G and R values in sequence, and the Y channel output B and G values. I noticed that the register go some values but if I use the VSYNC and HREF signal from the camera sent directly to the monitor, nothing showed up.

I also use the FPGA to count numbers of HSYNC in a frame. The FPGA counted about 424 HREF signals plus minus 10 more. I'm wondering how come the number is not consistent? And why is it not close to 492 (I'm expecting

492 lines for VGA output).

I'm wondering if this is because the sampling clock my FPGA use (50MHz) is not sufficient to sample the pixel information (13MHz) for progressive, RGB, 16-bit mode? Would anyone recommend taking out the camera's oscillator, connect the JP1 jumper and give the camera and external clock from the FPGA?

I also noticed a discrepancy in the camera's data sheets. It says that if it were to be set as a slave with an external clock provided, the VSYNC signal must be provided to the camera. The VSYNC signal must follow the formula: 525*2*858*Tclk - which will only give about 30Hz/fps for an 25MHz clock input? I need a 60Hz output for the monitor. Currently with the camera's original oscillator, I observed 60Hz VSYNC signal given by the camera. Why the disagreement?

Can anyone offer me any help on these questions? Any amount of input will be appreciated.

Thanks ahead.

Reply to
dalle002

Hello again,

Thanks to your input, the I2C register has been written succesfully!

The next question is: Does anyone have output the digital signal to a VGA monitor successfully? I am assuming that today's computer monitor is progressive and should run at a minimum of 50Hz. But when the camera is in progressive mode, the VSYNC signal is only at 30Hz. I tried to lower the resolution to QVGA but still got 30Hz in progressive mode. The 30Hz signal cannot be displayed succesfully if sent directly to the monitor. I used only the HSYNC and VSYNC signal from the camera and use the FPGA to do a counting to provide the RGB signal output, but the monitor is blank even thought the pilot LED sense an incoming signal(the LED on the monitor that turns orange when there is no signal and turns green when the computer is running). Any suggestion for solving the problem without using a memory module?

Thank you ahead.

Reply to
dalle002

Glad to see you have made progress...

I think you will find that difficult, because the first paragraph of the data sheet I have states

"The devices incorporate a 640 x 480 image array capable of operating at up to 30 frames per second."

So it is NOT possible to get VGA resolution continuously at 60fps. INTERLACED at 60fps (NTSC timings) should be possible.

QVGA at 60fps is possible.

That is because the device only has 2 A/Ds and that is primarily meant for still images or QVGA 'movies' as progrssive scan in digital format to be processed externally. It is NOT meant as a standard video camera. This is one of the standard modes which you will have to control by the I2C to change to any other format.

Because you have data and timing for basically still image capture, not as a continuous progressive scan video camera. You will need a video (not PC graphics) monitor to display an interlaced mode image.

Clocking from the FPGA is an option but understand the timing and max clock of 30MHz that must drive the camera, perhaps sort timings for

25MHz clock to camera. Your discrepancies depend on how you are clocking the count and saving results and reading the results. Are you clearing the count during vertical and missing the HSYNCs during vertical sync or worse still during vertical blanking.

Understand the differences between frames and fields, in relation to progressive and interlaced scan.

Interlaced scan gives 30 FRAMES per second consisting of 60 FIELDS, hence 60Hz VSYNC.

Progressive scan gives 30 FRAMES per second hence 30Hz VSYNC

The data sheet is badly written (appears to have been translated via

10 languages and back again) and has a few typos in it.
--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

See my other post.

The light on the front of the monitor only indicates that it has detected a sync signal, not if it is valid or not.

Try setting the camera to colour bar test pattern output (Reg 12 Common Control A bit 1), via the I2C to avoid other errors look at the pattern coming out of the chip.

Get the registers set correctly for VGA interlaced 30fps, and use the FPGA and some timing changes to output the faster timing and repeat each line as a start. This is minimal memory requirements and two line FIFOs should be possible inside a FPGA. Understand fully the timing patterns you have to create to drive a monitor as VGA progressive scan mode at 60FPS.

Clock the camera from the FPGA at 25MHz and use the 50MHz FPGA clock to derive the output timing.

Consult some good books on video like (if still available)

Video Demystified - A Handbook for the Digital Engineer By Keith Jack of Brooktree (when they made interesting chips)

ISBN 1-878707-09-4

See the November issue of Circuit Cellar for a VGA controller design

Reply to
Paul Carpenter

Hello,

Thanks again for all your help. It has been very helpful. I have successfully display the image from the camera onto the VGA monitor according to Paul's suggestion by deinterlacing. Wohooo! Thank you so much!

I took out the crystal oscillator off the camera board and use the FPGA to clock the camera at 25MHz. The camera is run at RGB Interlaced mode. Then I used the camera's VSYNC signal directly to the monitor but the FPGA is the one that generates the HSYNC signal to the monitor for 480 lines. In interlaced mode, the camera only gives 240 lines per field. Each line the camera output is put in registers and sent to the monitor twice to deinterlace it. It works fine!

Thanks again for all the help.

Reply to
dalle002

Glad it worked out for you.

This has been the start of a long road of understanding video...

Good to see a plan come together...

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.