I2C Woes, Opencore and Terasic

[Altera_Forum]

I've been trying to get a functional I2C bus in my design for a while now with no luck. I've tried my own and a few open source cores. ALL of them have the same problem. I never receive ACKs. I cannot figure out for the life of me why not. 

  I'm working on my graduate work and this I2C problem wasn't supposed to be a problem. I've got no work done and can't progress until I can talk to my D5M camera (also, the D5M library I tried didn't work either). I know it's a problem with me, it's in my circuit somewhere but I must not be experienced enough to locate it.    I've posted a logic analyzer screenshot or my current design with the Terasic demo for the D5M. They get an ACK, I don't. I looked at the code that accompanies the demo but it's so obfuscated I don't see much hope in using it for my design. I can see what's going on: they're just controlling the line bit by bit, but they get ACKs!   I've also provided some code snippets. One is my own code implementing a downloaded IP that uses the wishbone bus, which I now have working aside from acknowledgements, and the Terasic demo for the D5M camera. Any help would be great. Also, if there's something I'm missing (which I'm sure is probably the case) about verilog assignments and driving bidirectional pins, where do I go for more help? I'm lost and out of ideas. Thanks everyone.  edit: I'd also like to point out I'm having the same issue with the on board audio chip (WM8731) on my DE2-115. The Altera demo works (ACKs) but my cores, as well as the University Program core, does not.

[Altera_Forum]

I can't see the problem from the provided snippets. Driving SDA in a push-pull manner instead of open drain would be a plausible reason for failure. You would be able to recognize the problem from an analog SDA waveform, but possibly not from the digital logic level. 

 But we would need to see the code.

[Altera_Forum]

Are the two waveform captures supposed to be of the same attempted I2C sequence? 

 You can't see all the address bits in the second image, but the address bits seem to be mirror images of each other as if one was sent MSB first (correct) and the other LSB first (wrong).  Edit:  Now that I look at it again, you can ignore the above comment. The address bits (at least the ones we can see) do look consistent between the two images as FvM has pointed out in the next post.

[Altera_Forum]

Unfortunately, the second waveform has the start bit and several bits cut on the left. But as far as I understand, both are sending 0xBA as address byte, as the analyzer decodes. In, the lower waveform, the address is acknowledged, in the upper it isn't. Assuming, that a slave hearing on this address is connected in both cases, there are two explanations: 

- the slave is stuck somehow (shouldn't happen after a stop) - SDA is erroneously driven high by the master, overriding the slave

[Altera_Forum]

Thanks guys, I've also thought the master was driving it high but failed to find out why. Since you need more code (I thought you might but since I can't find the bug I was unsure what to post and didn't want to upload all of it for fear of bloating the post) I'll try to clean it up a little in the near future. 

 I found some more demos from Altera that look like they're made specifically for the audio chip and D5M camera and are also usable so I'm going to test them first. If they work I'll go back to debugging my core since I'd like a generalized version. Thanks for the input I'll get you some more information.  Also, I do have an oscilloscope and I'll take some readings with that as well. Thanks!

[Altera_Forum]

--- Quote Start ---  I was unsure what to post and didn't want to upload all of it for fear of bloating the post) I'll try to clean it up a little in the near future.  --- Quote End ---    That's appreciated. But you have also the option to append source files or a Quartus project archive. The latter is a convenient way to allow others to reproduce a problem.

[Altera_Forum]

I've had problems with I2C interface with a Maxim part. When I send a command to start ADC conversion for the first time I never get an acknowledge. However, if I put a time out timer on the ACK, and then send a second command everything starts working fine.

[Altera_Forum]

Sorry for deviating away from ur topic.....but i think u will be the right person to help me in the following issue: 

   I m having a edge detection project,where they used a TRDB_DC2(1.3 MP camera).... My doubt is if i use TRDB_d5m Camera...will i get the output....without making any changes in the project i have? thnx in advance!!

[Altera_Forum]

Sadiq, sorry I don't know. You can get the D5M datasheet from Terasic and compare it to the DC2 datasheet. You should be able to see pretty quickly if they're at least similar. I'd say probably not since they have different specs. 

 Also, to add to the original topic I seem to have found the issue. Instead of declaring an sda wire, putting this wire as the output of the module, and assigning that wire to the I2C lines I just assigned the I2C pins directly as the output of the module. I don't really understand why but now my original core works.   I discovered this when trying to use the I2C_Controller.v file. It still did not work until I wired it in the fashion described. I do notice the location of the buffer is different on the RTL schematic. That was a fun two months debugging! :D

[Altera_Forum]

thnx a alot...!! Incase if i encounter any other problem..can i ask u if u dont mind!!?

[Altera_Forum]

This problem troubled me for about 4 weeks, until I changed  

assign scl_pad = scl_padoen_o?1'bz:scl_pad_o; into   assign scl_pad = scl_padoen_o?1'b1:scl_pad_o;  Really a pain in the back.  There is no difference in the waveform captured by oscilloscope. Can anyone explain why?

[Altera_Forum]

I would expect, that the I2C core has no problems to work with open drain SCL operation, which is according to the standard. It may be however a hardware related issue of a missing or too high resistance pull-up, or strong crosstalk from other signals (possibly SDA) to the SCL node. As long as no I2C device is utilizing clock stretching, push-pull drive of SCL shouldn't be a problem. 

 P.S.: The I2C standard requires I2C devices to filter spikes at both bus lines. I'm missing this feature from the I2C core itself, however.

[Altera_Forum]

--- Quote Start ---  P.S.: The I2C standard requires I2C devices to filter spikes at both bus lines. I'm missing this feature from the I2C core itself, however.  --- Quote End ---   That is very strict. Do you know of any core that does this? If the I2C device(s) are on on the same board or in the same case, I wouldn't bother. I would not even bother if it was over a cable of xx meter, as long as the cable is well designed.