• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 101 subscribers
  • Views 13378 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How can I2C controller handle SCCB’s “Don’t care” bit?

Anonymous
Anonymous
Guru 17045 points

Hi,

 

I would like to ask a question on I2C controller (DM6437)'s communication with OV SCCB.

 

 

 

A difference between I2C is that for I2C there is an ACK (acknowledgement) bit (9th bit) after each byte of transmission, but for SCCB this 9th bit is "Don't care". 

 

For standard I2C in master transmit mode, the slave is supposed to acknowledge the byte sent by the master by pulling down the SDA during the ACK bit time; however for OV SCCB, it seems that “Don’t care” bit can take either 0 or 1 and is not functionally doing any “acknowledgement”.

 

The problem is on the master side. In I2C, the master (according to my understanding) is going to read SDA during the ACK time: If ACK is low, then it would then know the previous byte has been successfully sent and then it will proceed to the next byte or stop; if ACK is high, something else will happen (I am not quite clear on what will happen here). Anyway, we see that in standard I2C the master is expecting a meaningful ACK bit from the slave after sending each byte.

 

However for SCCB, since the 9th bit is “Don’t care”, the slave can either keep SDA high or pull it low during this I2C’s ACK time. So if it chose to keep SDA high, what will happen when master reads SDA to know the acknowledgement status of the slave? Won’t it interpret the high SDA as a signal that the slave hasn’t successfully received the data? Would the master still proceed regardless of the high SDA bit, abort the process, or repeat the previous transaction (sending)?

 

This is my question on why DaVinci’s I2C controller can communicate with SCCB. Could anyone help on this?

  

  

Zheng

 

 

  • 0
    Genius 3575 points

    All I can say is that you have very fine control over the behavior of the I2C bus by register access.  The programmer can define the i2c peripheral behavior for cases when no ACK bit is received.  This means you will probably have to write your own i2c controller software if you want to strictly conform with the spec you have posted.  You'll have to study the i2c app note for the dm6437 family in depth to figure out how to do that.

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

     

     

    Do you mean this IGNACK bit in the ICEMDR register?

     

     

    Zheng

  • 0 in reply to Anonymous
    Genius 3575 points

    That looks like a potential solution to your posted problem.  Have you actually hooked a camera up and tried to communicate with it using the standard i2c drivers?

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

     

    I am actually having an OV camera soldered on my board. Without setting the IGNACK bit, I get the following waveform for write to address 0x2b (a "nonsense" address purely for testing waveform generation):

     

     

    0010 1011 0 : the first bit ignored, the last appended bit is 0 for writing operation.

     

    However, there is no ensuing intended data in the wave form, and when I am checking ICSTR.ICXRDY bit (Interrupt Status Register . Transmit-data-ready flag bit), it remained zero for the while loop. Therefore I suspect the I2C has got "stuck" there, waiting vainly there for the receiver's acknowledge bit (pulling SDA low).

     

     

    I have currently enabled the IGNACK bit, but the change in the waveform hasn't come yet. Does this need to be applied in conjunction with some other register settings?

     

     

    Zheng

     

     

     

     

     

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

     

    It is done now and the expected waveform (address followed by actual data) can now be detected. When I said I still haven't detected the desired waveform even after changing the IGNACK bit, I was simply tracing in the program and found the while loop was still executing, probably due to some other cause. But the waveform can clearly be observed.

     

    I would like to express my deep appreciation for your confirmation at the beginning (in another post) that I2C controller is capable of communicating with SCCB. Without this guarantee I probably would not even delve into the document further and I was actually considering some re-soldering for GPIO simulation.

     

     

    Zheng

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

    I still have an additional question. In your system did you ever observed OV camera acknowledging the master by pulling SDA low? In my experiment SDA always remain high during ACK bit periods.

     

    Zheng

  • 0 in reply to Anonymous
    Genius 3575 points

    I can't recall which Omnivision part I was trying out, but I seem to recall that it was responding with an ACK on the i2c bus.  It may be that some devices are "more" i2c compliant than other devices.

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

    When you say "responding with an ACK on the i2c bus", do you mean it drive the SDA low?

     

    Zheng

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

    If DM6437 can be configured to ignore "Don't care" bit (not requiring slave to pull SDA low as in normal I2C ACK), then I think in principle it should be capable of driving all two-wire SCCB devices. What's your opinion?

    My current problem is that my writing into the registers seems to have no effect. For example, I tried to change the PCLK output value by writing a specific register 0x11 with clock prescaler value, but the PCLK doesn't change at all in response to it. There is also no SDA's being pulled low during the "Don't care" bit.

     

     

    Zheng

  • 0 in reply to Anonymous
    Genius 3575 points

    I think you need to back up a step and try to read a register with a known value from your sensor.  Most cameras have a device id register that you should be able to read.  Until you can read that register and get results that match the expected value from the datasheet, I wouldn't assume your communication is working.

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

    Thanks, I will try this test.

     

    Zheng

  • Anonymous
    0 Anonymous in reply to MattLipsey
    Guru 17045 points

    Matt,

    Have you ever got the need to add some delay between START condition and the actual slave address? On a "golden standard" SCCB driving device's waveform I have noticed this approximately 60 µs delay, but have not been able to mimic this using DM6437's I2C controller. This is described in How to control delay time after I2C controller’s START condition? Could you have a look at it?

     

     

    Zheng

  • 0 in reply to Anonymous
    Prodigy 150 points

    Hi All,

    I am trying to interface MSP430F55XX series controller to OV2640. I have checked the waveforms on I2C lines and can confirm that the 9th bit which is ACK from OV2640 is not driven by OV2640 and is left in high state and thus the I2C communication is unsuccessful. 

    Is writing own I2C driver the only option? Is there any other way to configure the I2C to ignore the ACK bit and continue writing or reading data?