Problems in the I2C master

Hi everyone

I have a problem with my I2C master but I dont know which could be the problem.
The pictures show the write and read cycle.




The frequency of the clock is 377Khz and the frequency of the scl is 190Khz.
I am trying to conect to HDMI-FMC through using a Terasic V but for any reason it doesnt work.
Do you see something wrong in the write/read cycle? Do you know what could be the problem? I dont have too much experience in this kind of things and I am very desesperate.

Thanks so much
Pablo

I fear, the wave isn't very informative without the test bench code (I presume it's a simulation). What do you test the master against? How do you implement the SDA pull-up? Also the wave starts somewhere in the middle, not showing the start transaction.

Hi,

.. and please give a detailed error description.

* What do you expect?
* and how does it behave instead?

Klaus

First of all thanks for the answerd and I am so sorry because I don't have too much experience in these things and I dont know how explain the situation very well.

I am using a Terasic V (Altera) and I have to connect to a HDMI-FMC (https://www.analog.com/media/cn/tec...tion-documentation/UG-237.pdf?doc=ADV7619.pdf) by I2C. It means, my slave is a real slave (other board). First, I did a simulation of the master which I showed you. After that, I proved this code in the board but I receive a Non-ack ('1') instead a ack ('0') from the slave so something is wrong. The slave_add is correct (0x98) so I supposed that there are something wrong in my code. I don't know what could be the problem. I checked the protocol more in detail but I didn't find nothing wrong in the shape of my waves. Because of that, I showed you just the simulation of the master I2C to make sure that the waves are correct. Of course, I proved it with a slave, but I did the slave myself and it worked but it is not a good reference because I did it. Maybe it is wrong too.
Here I attach the real simulation in signal_tap of QuartusII. In this picture you can see that the master try to connect but it receives a Non-Ack, it stops the transmission and it tries again.



On the other hand, I dont know what you mean with the question "How do you implement the SDA pull-up?".

If you need more data just say me.
Thanks a lot
Pablo

Hi,

* please review your SCL/SDA timing. It seems your SDA_transition meets the falling edge of SCL. This is not allowed. During data_transmission SDA must change only during LOW phase of SCL, with sufficient distance to the clock edges.

* Please verify: VS/FIELD/ALSB is left unconnected?

Please show a scope picture of the real signals: SCL and SDA in one picture. STATRT, SLAVE_ADDRESS, RW, ACK ... at least.

Klaus

I was under the assumption that you simulated the master with a slave model, which would be the preferred procedure. Thus my question about SDA pull-up. It would be generated in the test bench by a weak high driver for SDA. If SCL uses open drain as suggested by the I2C standard, it needs a pull-up too.

If no slave is utilizing clock stretching, SCL can be driven push-pull in a simplified master. SDA should however use open drain driver, apparently not implemented in your code.

Before spending the effort to code an I2C slave model, or search it on the internet, you could compare the timing of the master simulation against I2C specification. At first sight, you are missing to generate a correct start sequence, a sufficient condition for master failure.

Hi again

I checked your answers and I change my code. I would like to make sure that the protocol is good implemented. Because for example, I don't know why you say that my start condition is wrong . I attach the timing table and the simulation of the master whiout any slave, as I said you before I dont have slave code, just real code (chip). The data and address values are random.

**broken link removed**
I2C timing
**broken link removed**
Write cycle
**broken link removed**
Read cycle

Part1 (Stop and Start condition)

Part2 Changed data when scl=0

Part3 The first half cycle of the mem_add is in Z value because the slave still is transmiting.

Part4 (repeat start condition)

I think that everything is okay but I am not sure. If you can verify please or give me some good paper where I can read.
On the other hand I read that the SCL signal could be INOUT. It is when there are more than one master, right?.

Thanks a lot!!
Pablo

For I2C timing, I would always refer to original Philips/NXP I2C Bus Specification document UM10204.

The timing looks basically good, bit delays are usually not critical, most I2C devices also support 400 kHz I2C operation.

As for SCL open drain versus push-pull operation, besides multi master it's also required for clock stretching, like most slave devices, ADV7619 apparently doesn't use it.

Hi again

I changed the code, like I said you in the last message, and I have proved in the board but it still doesn't work and now I dont know what could be happened. Any idea?
The slave answers me a "1" non-ack but I am not if this "1" is the answer of the slave of it is my own "Z" level that I use in this period to allow writting the slave.
I attach you the real simulation in the board with the signals CS, RS_N and, Int (output).



The slave address (IO map) in the paper (**broken link removed**) says that is x98. In the simulation the value is CCh because I use the last bit for other stuff but in the SDA transmission the slave address is "10011000" = x"98".

Thanks for all
Pablo

Hi,

The slave answers me a "1" non-ack but I am not if this "1" is the answer of the slave of it is my own "Z" level that I use in this period to allow writting the slave.

Click to expand...

There is no difference:
Mind: master as well as slave never give "1" to the SDA. Only either they do nothing = "Z", or the pull it to GND ="0".

Thus NOT "0" (= Z = pulled up to HIGH) means non_ack.
It simply is "no answer".

Your pictures look like a simulation. Please show us scope picture of the real communication.

In the simulation the value is CCh because

Click to expand...

I see no "CCh".

Klaus