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.

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.

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.