EmbeddedRelated.com
Forums

OV7620 image sensor interface with FPGA headache

Started by dalle002 November 15, 2004
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

On Monday, in article
     <85ba9fbbc8922505cf3632db7049cf71@localhost.talkaboutelectronicequipment.com>
     dwmunandar@yahoo.com "dalle002" wrote:

>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.
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.
>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.
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.
>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.
See above, I doubt the sensor is burned.
>Thanks in advance! > >Dalle > >
-- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
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.

On Mon, 15 Nov 2004 21:16:47 -0500, "dalle002" <dwmunandar@yahoo.com> wrote:

<snip>
> and use an external >resistor - I connect the SDA to a 5v source through a 300k resistor
<snip>
>Which part did I do wrong this time?
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
Dalle,

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

HTH,
-- Georgi

"dalle002" <dwmunandar@yahoo.com> wrote in message
news:85ba9fbbc8922505cf3632db7049cf71@localhost.talkaboutelectronicequipment.com...
> 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 >
> 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
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 ;-)
On Monday, in article
     <34db81a15d5978ad5867aff80e61e800@localhost.talkaboutelectronicequipment.com>
     dwmunandar@yahoo.com "dalle002" wrote:

>Hello, > >Thank you for your immediate response! I tried to follow your instructions >as I understand it. This is what I did.
As others have said check that the sensor has I2C enabled (I forgot that most need this enabled).
>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.
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.
>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.
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.
>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.
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.
>Any more help will be really appreciated. I almost completely lost any >ideas and hope trying to get this project going.
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 <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
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.




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.

On Friday, in article
     <eb85bd6eab936116056f3a4830038d87@localhost.talkaboutelectronicequipment.com>
     dwmunandar@yahoo.com "dalle002" wrote:

>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.
Glad to see you have made progress...
>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 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.
>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.
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.
> 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.
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.
>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?
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.
>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?
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.
>Can anyone offer me any help on these questions? Any amount of input will >be appreciated. > >Thanks ahead.
-- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate