Omnivision OV7640 SCCB (I2C?) bus problem

Neglecting the rest of the post (sorry, can't answer it), bayer encoded data looks OK, unless you look really closely. For example, look at a very red object, and you'll see when you zoom in that only a quarter of the dots are lit. If you don't look closely, then it's broadly a greyscale image, dominated by the green in the original image.

Depending on the data format that sounds about right.

As per other post, you probably have 565 format which gives grren dominance, of you are getting Y dominance in the data values.

So you are getting Y dominance in your data.

You driving something as open-collector/drain configuration for the port pin? If not you will NOT see acknowledge bits properly.

You are letting the output of the port pin FLOAT, and an external pullup resistor pull the value to rail, then READING the bit setting to determine if the slave device has pulled down the SDA line to give you a proper ACK.

When you have no acknowledge at this point you have not addressed the device correctly or actually got your signal to the sensor. With a scope measure the signals at the OV7640 pins, if necessary set another port pin high at start of I2C bit banging to trigger the scope on stop conditions and low on stop conditions.

Anything beyond this point is pointless until your address is acknowledged correctly as I doubt you are properly allowing the ACK bit to get back to the PIC through your level translators. You are sure that your level translators used are BI-directional?

...

As far as I know yes. I think you have a hardware problem, or not bit banging correctly.

You need to let an open collector/drain output turn OFF to allow the line to be pulled up by an EXTERNAL resistor to all the slave device to drive the line low, which you then READ in the Master device.

The MASTER deasserts (floats) the line, to be pulled up by external resistor, the slave (OV7640) drives the line low, the MASTER (PIC etc) READS the line to see if pulled low.

...

Use another port pin toggled by your start/stop functions to trigger the scope.

You have got pull up resistors BOTH sides of your level translators?

You have measured the signals and timing relationships at the OV7640?

Hello Ian & Paul,

Many thanks for your input on the data I'm seeing coming out of the sensor. I will work on this once I've got the I2C going.

I expect I can set the registers such that I get RGB data out, which is then easy for me to manipulate.

Turning to Paul's response :

I am using the PIC's I2C port on Pins RC4 (data) and RC3 (clock), in an open-collector configuration with pull-up resistors (as part of the level translation).

The level translation circuit is bi-directional. Maxim has a detailed description of this circuit and how it works here :

However, I will check with the BSN20 MOSFET's I've used, whether the voltage levels (resulting from level shifting) are within the tolerance of both the PIC and OV7640.

I've put an extract of my circuit on the web here :

Certainly, when I looked at the waveforms on the copper track connected directly to the OV7640, qualitiatively they looked like the waveforms on the PIC side, just with a lower amplitude. Your comments have triggered another possibility in my mind. The slew rate of the level translation may be a factor. I will look in more detail at that as well.

Is there a MINIMUM speed one can run I2C at? ie: If I ran the I2C clock at 10kHz, should it work? This would allow me to negate the effect of the rise time of the level shifter.

Regarding cycling the read/write repetitively, I was wonderfing if the OV7640 could "keep up". For example, I know with I2C EEPROMs, the time taken to write a byte is significant relative to the maximum speed of an I2C bus, and therefore, the master has to "poll" the EEPROM until it gets an acknowledge. I was wondering if a similar situation held true for the OV7640. (I wouldn't have thought it would on a read cycle)

I will start by looking in more detail at the voltage levels on both sides of the translator. Then I will write code that controls the clock and data pins directly, rather than using the PIC's internal I2C registers, and see where that gets me.

Paul.

Nothing obviously wrong with it, but I have not looked at the MOSFET spec.

You could always lower the pullup value from 4k7 to 1k to see faster rise times.

Not that I have come across as it is state/clock driven, you could run it at less than 1Hz.

Firstly never send the I2C stop until the whole read and write transaction (address, data,....) has completed. Otherwise you abort transactions and the next data read/write would be considered as an address sequence.

Secondly EEPROMs take a long time to write internally and I am sure you don't have to wait a long time for an acknowledge to the address as that should be next 'clock' cycle.

Thirdly I have not seen any Omnivision chips that could not handle I2C as normal, no long wait times as it is writing to and reading from registers, not special memory.

Try -

Hello Paul,

Very many thanks for your reply and advice.

Working slightly backwards in your order of suggestions, I finished writing the code to drive the I2C directly around 11PM last night and found a couple of errors in it this morning.

The most glaring problem on testing it was that I was unable to get SDA to go low ; not wanting to desolder the SMD components I set up a PIC on a breadboard and have recreated the problem. I must have a mistake where I set up the port for I/O. My breadboard was simply a PIC18F448 with two resistors connected to RC3 and RC4, so my problem must be software.

Thank you for your suggestion about resetting the OV7640 after each test ; I haven't been doing that ; I will incorporate that into the code.

Paul.

Please note that you cannot write ones to the I2C bus, you have to disable the output instead to get a passive one, like an open-drain output.

CHECK THE HIGH THTRESHOLDS FOR THE PIC I2C PORT PIN INPUTS BEFORE DOING THIS. ======

Which reminds me if the ONLY thing on your I2C bus is the OV7640 and the PIC thresholds allow for 3V levels on the I2C bus, drive the I2C with

With a low pull-up value you will have fast slew rates and minimal components.

You could always put clamping diodes on the lines to protect the OV7640 by ensuring the pins do not drive more than 3V3 out from the PIC.

Hi

I'm happy I'm not the only one in the world to have proble

configuring these cameras...

I'm using a OV7141, so the same camera but B&W. I'm configurin

the camera with a PIC core intergrated on a SPARTAN IIE FPGA. I hav

I supplied the camera with 2,5V as it is indicated in the datashee

(and not 3V3 which is too high for some input voltages) and the FPG is 3V3

The only difference I notice from I2C is that the camera "may not

answer to the ack(called don't care bit) ! And it doesn't wih what can observe on my scope

In the datasheet

"The Don?t-Care bit is the 9th bit of a master-issue

transmission; ID address, sub-address and write data. The master wil continue to assert transmission phases until the transmission cycle i complete. The master also assumes that there is no transmission erro during data transmissions. The purpose of the Don?t-Care 9th bit i to indicate the completion of the transmission When there is more than one slave on the bus, the slave(s) may respon to the Don?t-Care bit in one of two ways. If slave 1 is selected an data is written to this specific slave, slave 1 will drive SIO_D t logical 0 for the Don?t-Care bit. In this case, the SIO_D signal ma conflict at the beginning of the Don?t-Care bit, while it may b floating at the end of the Don?t-Care bit Alternately, it is possible that the slave(s) do not respond to th Don?t-Care bit of the current phase. In this situation, the SIO_D bu remains at float for the whole Don?t-Care bit."

If someone managed to configure a Omnivision camera yet, it woul

really help me a lot

Thanks

Thank you for the additional suggestions.

I'm sorry if I wasn't clear in my description. I was releasing the tri-state to form a passive "1" rather than driving the output high.

Turns out that for a PIC18F8620 V Input High = 0.7Vdd for RC3 and RC4 That equals 3.5V and since the OV7640 has its IO fed at 3.3V, clearly a simple resistor configration fails. Pity, it was a simple solution with the clamping diodes. Still the BSN20 devices are not very expensive.

So, many code trials later, bit-banging problem fixed, and my problem is solved.

I wasn't getting an acknowledge from the OV7640 because I was not addressing it correctly.

The datasheet states : "The device slave addresses for the OV7640/OV7141 are 42 for write and 43 for read."

I took this to mean that the address was 01000010

So when addressing the device, one needed to send 10000100

(Shift the bits one to the left, and set the LSB to 0 to indicate a read.)

However, it appears the datasheet means that the bit sequence one uses for the addressing byte is 01000010, the LSB being 0 indicating a write.

For a read, the bit sequence is 01000011 this time the LSB is 1 indicating a read.

I have read out some of the read only register locations, obtaining the default values specified in the datasheet.

I will soon return to working on the image data which will no doubt throw up some more questions.

Paul.

Well worth a look...

As I think we all suspected earlier.

Forgot to check that, glad you have the problem solved.

Well at least you are progressing in the right direction. Good to hear things are starting to work.

The camera chip has Vdd-IO which should be 3V3, to match your FPGA.

Until you can address the camera and get a vlaid ACK to the address all the time, then everything else is pointless chasing.

Check as the other user that you are doing:-

READ 10000100x (0x42 shift left one)

Write 10000111x (0x43 shift left one) ÝÝ Write bit- ----- Ack bit (write to SDA line so it floats high)

Yes the problems are not usually the camera chip, but understanding I2C and Omnivisions poor SCCB descriptions in order to avoid I2C patents.

The fact they use a different address for read and write is also confusing and bad use of the I2C bus, when it could mean they had two or more cameras on the same bus.

-- Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services GNU H8 & mailing list info For those web sites you hate

Thanks a lot for your help

I'll try this and tell you if it works

Hello Paul and Vinch,

Just to clarify, the bit sequence I used to address the OV7640 was

READ 01000010x (0x42)

WRITE 01000011x (0x43)

ie : I didn't shift the bits one to the left. I really believed given the way the information was presented in the datasheet that I needed to shift the bits one to the left, but empirically I found this not to be the case.

Paul.

Hi Paul,

The camera is still not answering (pulling down SDA pin) even if

send 42h as write address (0100 0010). I'm recording SDA and SC sequence that's sending my fpga with an oscilloscope and the SD remains high. The timings I have are really higher than the spec o the SCCB (SCL high during 50us !) I added two pullups on SDA SCL, and this time instead of applying a on SDA, I realise it from the ground as you did

Do you have a schematic of your circuit ? Can I have a look at you

code

Thank yo

Vincen

READ address.

You should have a pullup to 3V3 on the SDA and SCL line 2k or higher. The OV7640 should be powered at 3V3 on VDD-IO (only), and the FPGA I/O should be powered at 3V3 for that bank at least.

The fpga pins that drive SDA and SCL must be open-drain configuration, whilst waiting for the ack bit you MUST set the SDA output from the FPGA to open-drain (pseudo drive high where the pullup resistor drives the line). If the FPGA is ACTIVELY driving the line you won't see a low.

What exact voltage levels are you getting before and after the ack bit time and for '1' and '0' during the address bits? You may have the FPGA or soemthing else actively driving the line high during this bit time, which will give a slightly different voltage level (example 3.1V instead of 3.3V).

I don't have FPGA code for such a setup and I have used bit banging from ports and Philips PCF8584 I2C controller for such tasks. There are examples about like fclib if you search for that as an example for Altera PLD I2C slave/master.

=_NextPart_000_00A3_01C5685E.DBDD11C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The datasheet reads : "The device slave addresses for the OV7640/OV7141 = are 42 for write and 43 for read."

Part of my schematic, at least the part including the OV7640 is here : =

The FET's are level shifters since the PIC is running at 5V and the = OV7640 runs on 3.3V =20

from

examples

I2C

My code is also on a PIC.

Among many others, I read the following webpage : =

I didn't find Omnvision parts easy to source, in fact, I only found one = supplier :

Where else are OV products available?

Paul.

mutter, mutter, mutter....

Must remember when house full of builders, don't rely on another posting double check the datasheet.

In UK I beleive they are the only source, but I have had varying degrees of success with that company over the years with various parts, and part shipments.

According to their website

Telecom Design Communications Ltd.

Tel: +44(0)1256 332800 Fax: +44 (0)1256 332810

Website:

.....

Another unread message because of the html or mime encoding. Usenet is a pure text mechanism.

-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson

Sorry! I think it was as a result of cutting and pasting from the datasheet into the reply.