i2c problem--no ack from slave device

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to talk to an Omnivision 6620 CMOS camera module via the i2c bus (same one the AVR-cam and CMUcam projects use). I'm pretty sure I have everything hooked up right (I've triple checked it), but for whatever reason the OV6620 is not returning an ack.

I have hooked up the scl and sda lines to a scope and I can see that the slave address of the camera (0xC0) is getting clocked in after the first 8 clock cycles, and then the slave device is supposed to pull the SDA line low to ACK the address that it was sent on the 9th clock ; however, the OV6620 isn't acknowledging it.

I'll get a screen shot of the scope shortly showing the problem more in depth. Also, I'm using the I2Cinterface that's used in the AVRcam code.

I was wondering if anyone has possibly run into this before, or if they know why the OV6620 wouldn't be able to ACK back to the mega128.

Thanks!
Dan

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You connected SDA and SCL but did you also connect a common ground? If you don't have a common ground, there is nothing valid for the module to reference against, thus it may never see the signals on SDA and SCL.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One other possibility is that the address (0xC0) is not what the camera module wanted to see. 0xC0 started out life as 0x60, which is reasonable enough.

Another possibility is that the clock frequency is too high.

Yet another possibility is that the pullup resistors on the TWI bus are the wrong values. Generally, you want roughly 1.8 K to about 4.7K, although you can make arguments for different values.

Harvey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
You connected SDA and SCL but did you also connect a common ground? If you don't have a common ground, there is nothing valid for the module to reference against, thus it may never see the signals on SDA and SCL.

Yes, there is a common ground between the two.

Quote:
One other possibility is that the address (0xC0) is not what the camera module wanted to see. 0xC0 started out life as 0x60, which is reasonable enough.

Another possibility is that the clock frequency is too high.

Yet another possibility is that the pullup resistors on the TWI bus are the wrong values. Generally, you want roughly 1.8 K to about 4.7K, although you can make arguments for different values.

In the data sheet for the camera, it says 0xC0 (for writing, reading would be 0xC1), so I'm pretty sure that's the address.

On the scope, it shows the frequency of the i2c SCL line as being 100 Khz, which is what it should be.

Also, I have tried using pullup resistors of 10k and using just the ones that are internal to the Mega128.

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just attached a drawing I did to try and visually illustrate the problem I am having. Hopefully this helps. On the 9th clock, if an ack occurs, the slave device should be pulling the SDA line low, and it's not, thus I'm getting a NACK.

edit: the picture looks really bad on here, you can just go straight to here:

http://www.users.muohio.edu/ande...

to see a better picture of it.

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An analog scope would show the waveforms better. The pull-up resistor is only one responsible for the low-to-high transition speed. You don't say what voltage you use, but for 5V I'd use pull-up resistors of around 2k2 to 4k7, 10k might work okay, but you would have to see it for yourself with an analog scope.

For 3.3V, I'd use something from 1k2 to 4k7 maybe. In either case, the internal pull-ups on AVR are equivalent to around 20k..100k, so they are by themselves way too weak.

So see the signals with an analog scope, and see that the camera module has other pins connected correctly (like reset pins or I2C address selection pins or powerdown pins and the like).

- Jani

EDIT: After hunting down the datasheet, you should check what you have on IICB, MULT and CS[0..1] pins too, not just reset and powerdown. You propably have configured the I2C address to something else than the default, or not enabled the I2C interface at all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was actually using an analog scope, I just drew out what I was seeing, but I took a picture of what the scope is actually displaying so here's the link to that:

http://www.users.muohio.edu/ande...

The bottom reading is the SCL while the top is the SDA.

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:

EDIT: After hunting down the datasheet, you should check what you have on IICB, MULT and CS[0..1] pins too, not just reset and powerdown. You propably have configured the I2C address to something else than the default, or not enabled the I2C interface at all.

Good idea, I'll look into that.

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using the C3088 module which contains the OV6620. I know the IICB and the MULT pins are set to the correct value because they aren't directly accessible on the pin out header (and the AVRcam project uses the C3088) . As far as the CS[0..1] pins, I tried address all of the different possible addresses it could be which are listed in the data sheet (there's 8 of them) and still got no ACK.

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, have the SDA and SCL lines connected correctly? If they are swapped by accident, or have a bad connection?

Can you put another I2C device there like 24xx serial eeprom, and talk to it to be sure of things?

And propably a stupid question, but does the camera get power :)

- Jani

Edit: So how are the reset and powerdown on the module connected? And are all power and ground pins connected?
Seems like a nice module.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The address coming out of the processor of 0xC0 is actually an address of 0x60.

Addresses run between 0 and 0x7F, which when shifted, give you 0 to 0xFF, and then the even/odd is read/write.

The waveforms look good, so the only possibilities are that the I2C address is wrong, or the I2C interface on the camera is not enabled.

If you have another I2C device, the idea of trying to see if something out there is alive is a good one.

The internal pullups on the I2C pins are disabled in the I2C mode, IIRC, so you must have pullups. However, the waveforms look good to me.

You're trying to read from the chip. That might not work, depending on how the camera is designed. While you *ought* to be able to read and write an address to any I2C device and see a response if it is addressed, most of the I2C devices operate something like this:

1) send out I2C write with the device address, sending an internal address (register) byte as data (or perhaps a count... I use a lot of that on my smart I2C stuff).

2) send out a read with the device address.

3) do sequential reads of the I2C bus, the responding device ought to be putting data on the bus at that time.

You may want to try writes first, depending on how the device is configured.

Harvey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:
Well, have the SDA and SCL lines connected correctly? If they are swapped by accident, or have a bad connection?

Can you put another I2C device there like 24xx serial eeprom, and talk to it to be sure of things?

And propably a stupid question, but does the camera get power :)

- Jani

Edit: So how are the reset and powerdown on the module connected? And are all power and ground pins connected?
Seems like a nice module.

I've triple checked the SDA and SCL lines and they do appear to be connected correctly.

I need to check and see if I have any other i2c devices laying around.

I'm pretty sure the camera gets power because if I look at the output of one of the Y lines on the scope, they are outputting a signal (it must just be whatever the default setup it set to do).

I have all grounds hooked into one common ground, as well as both VCCs are hooked up to the same 5v source that's powering the mega128...

This is what I have hooked up on the C3088 module:
power down -> GND
reset -> GND
SDA -> SDA
SCL -> SCL
analog ground -> GND
analog ground -> GND
VCC -> 5V
analog ground -> GND
VCC -> 5v
GND -> GND

(and that's exactly how everything is hooked up now)

Thanks!

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

NightSky wrote:
The address coming out of the processor of 0xC0 is actually an address of 0x60.

Addresses run between 0 and 0x7F, which when shifted, give you 0 to 0xFF, and then the even/odd is read/write.

The waveforms look good, so the only possibilities are that the I2C address is wrong, or the I2C interface on the camera is not enabled.

If you have another I2C device, the idea of trying to see if something out there is alive is a good one.

The internal pullups on the I2C pins are disabled in the I2C mode, IIRC, so you must have pullups. However, the waveforms look good to me.

You're trying to read from the chip. That might not work, depending on how the camera is designed. While you *ought* to be able to read and write an address to any I2C device and see a response if it is addressed, most of the I2C devices operate something like this:

1) send out I2C write with the device address, sending an internal address (register) byte as data (or perhaps a count... I use a lot of that on my smart I2C stuff).

2) send out a read with the device address.

3) do sequential reads of the I2C bus, the responding device ought to be putting data on the bus at that time.

You may want to try writes first, depending on how the device is configured.

Harvey

I'm confused about the whole addressing thing. Why does it matter if I shift 0x60 to the left by 1 instead of just setting it to 0xc0 in the first place?

Also, I think I would agree with you at this point that somehow the camera isn't getting initialized properly so that the i2c is activated--I just don't know why that's happening...

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't worry about the address. It is 0xc0/0xc1 when interpreted as 8-bit or 0x60 when interpreted as 7-bit address. I am not going to fight which one is more logical or politically correct :)

I'm not sure but does the camera require a reset via the reset pin or can it just boot with reset pin constantly in non-reset state?

Do you have same power supply for AVR and the cam module? How fast or slowly the power rises, have you tried different power supplies?

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:
Don't worry about the address. It is 0xc0/0xc1 when interpreted as 8-bit or 0x60 when interpreted as 7-bit address. I am not going to fight which one is more logical or politically correct :)

I'm not sure but does the camera require a reset via the reset pin or can it just boot with reset pin constantly in non-reset state?

Do you have same power supply for AVR and the cam module? How fast or slowly the power rises, have you tried different power supplies?

- Jani

Oh okay, I get the addressing issue now--thanks for clarifying.

The default for the reset is zero, so I'm pretty sure it can be booted with the reset pin in non-reset state.

The atmega128 is powered through the ISP cable that is hooked up to the STK500 (which is hooked up to a 12 v supply and it's being regulated down by the STK500 to 5 v). I also have a seperate 5 v supply hooked up to the camera module (I've tried it with the same one too).

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So basically, the 5V powers do not come from the same supply? So you power them up at different times?

If anything other than the I2C pins are connected (or even in that case possibly) the device that gets power first will possibly output power through it's data pins to the other device. They should be powered from the same 5V supply for starters. I hope you have not fried the camera module (as the AVR seems to be still working).

Hmm, have you connected the ground of the AVR board to the ground of the camera module? So are you absolutely sure the camera module gets power and it has a common ground with the AVR board?

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I switched it back so that both are getting from the same supply now.

I'm certain it's getting power because it's outputting digital data on it's Y0-Y7 ports as soon as it's turned on (verified on scope).

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I hooked up another i2c device and it's ACKing just fine, so the problem is obviously somewhere with the camera module. I'm not sure if I don't have it hooked up right (I thought I did), or if I fried it somewhere along the line so that it's i2c communication no longer works.

I guess I'll just have to get another camera module and see if that works... I really don't know what to do besides that at this point...

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have a link to the datasheet for the camera module?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the module and here is the camera chip .

First links if one bothers to type into google.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Jani, I tried to but just found weird stuff....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
Thanks Jani, I tried to but just found weird stuff....

No problem :) So did the links work for you ?

I've found google is sometimes country-specific, in a way. I get slightly different results from google.com than google.fi.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes the link worked, 8) trying to read up on I2C-part of the chip.
I normally use google.com don't know why it didn't work.
I did get a hit to some finnish school that had implemented it but as you know it's like greek for us Swedes. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
Yes the link worked, 8) trying to read up on I2C-part of the chip.
I normally use google.com don't know why it didn't work.
I did get a hit to some finnish school that had implemented it but as you know it's like greek for us Swedes. :)

:D Yes I believe you :) Men vi här måste lära oss svenska i grundskolan, i gymnasiet och även en kurs eller två i universitet. If that was correct :) Stockholm is a nice town, I spent three days there last summer. I particularly liked the free museums, went dancing in Djurgården, visited the technology museum, and went to Tom Tits Experiment. Wow, how offtopic can this get. Sorry.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sort of unfair, we don't need to learn finnish. :)
Free entry to museums is no more, we have a new government (right wing). :twisted:

Couldn't find anything special when I read datasheet.
As OP says MULT and SBB are supposed to be wired correctly on the board already.
I would try to toggle RESET just to be sure device hasn't locked up (not really probable).
If I2C was sent to a non-powered camera module there could be trouble.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried to toggle RESET, but still no go. Also, I'm sure the camera is getting power.

I must've accidently done something to the camera to mess up it's i2c lines (or it was dead on arrival). Maybe my next step would be to buy a new one?

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, thanks for all of your suggestions, I appreciate the help.

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, so I got a new C3088 module, hooked it up, and it ACKed just fine. So the problem was with the old module I was using (it either came broke or more than likely I must've fried the i2c communication on it somewhere along the line).

"I only speak one language .... 101001 ..." - Mr. Rat from The Core (r)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good to hear things are working now. :wink: