IIC protocol problem - A NACK is always issued after the slave device address is tx.

[dpaul]

Hello,

I have a working system in which a Xilinx AXI IIC IP (v1.02a) acts as the master transmitter and it is connected to an IIC slave (I2C Slave by Steve Fielding @ OpenCores). These two IPs belong to a uP system, so I basically write a C-code to test the IIC transactions (the uP generates AXI bus transactions which can R/W the registers of the Xilinx AXI IIC IP and as per command written in the control reg., IIC transactions are to be generated).

The problem is, I always see a NACK after the AXI_IIC master tries to put the slave device address on to the SDA bus; even though there is data queued in the tx_fifo of the IIC master. After that NACK and STOP condition, there is no IIC activity on SDA and SCL.
Why is this happening?

I have changed the device address in the file i2cSlave_define.v and everything which is supposed to be done as per the spec of the iic slave IP to make it workable. I am using the 'Dynamic Controller flow logic' of the AXI IIC master IP (Xilinx spec), and accordingly have written the C-code.

int main()
{
//-------------------------------------
// Test AXI_IIC_S0 'Dynamic IIC access'
//-------------------------------------
// 0xc0 menas FIFOs are empty
printf("\n AXI_IIC_SR_S0 = %8x \n", AXI_IIC_SR_S0);

// Initialization
// --------------
RX_FIFO_PIRQ_S0 = 0x0f; // Set rx_fifo depth to max
AXI_IIC_CR_S0 = 0x2; // Reset the TX_FIFO (0000, 010)

// Enable the AXI IIC, remove the TX_FIFO reset, disable the general call (0000, 001)
AXI_IIC_CR_S0 = 0x1;

// Write 4 bytes to an IIC Slave @ 0x34
// -------------------------------------
//AXI_IIC_SR_S0; // Chk all FIFOs empty and bus not busy

// Read the CR
AXI_IIC_CR_S0;

// Set start bit, device address and write access
AXI_IIC_TX_FIFO_S0 = 0x134; // Address of the slave device
// *** You can see this 0x34, device address, or 00110100 being tx. on the SDA

AXI_IIC_TX_FIFO_S0 = 0x00; // Register address of the slave for data transfer
AXI_IIC_TX_FIFO_S0 = 0x89; // Byte 1
AXI_IIC_TX_FIFO_S0 = 0xab; // Byte 2
AXI_IIC_TX_FIFO_S0 = 0xcd; // Byte 3
AXI_IIC_TX_FIFO_S0 = 0x2ef; // Byte4 and STOP bit

printf ("\n IIC_s0 operation done, begin IIC_s1 operation!\n");

return 0;
}

Attached below is the screenshot of my simulation.


One can see that on the 9th SCL pulse, SDA is HIGH which means a NACK as per Philips UM10204 spec. Now as per Pg10 of this spec-

There are five conditions that lead to the generation of a NACK:
1. No receiver is present on the bus with the transmitted address so there is no device to respond with an acknowledge.
2. The receiver is unable to receive or transmit because it is performing some real-time function and is not ready to start communication with the master.
3. During the transfer, the receiver gets data or commands that it does not understand.
4. During the transfer, the receiver cannot receive any more data bytes.
5. A master-receiver must signal the end of the transfer to the slave transmitter.

<1>, <2> and <5> are ruled out. I do have this IIC slave IP connected and have configured it to be at address 0x34 (by changing the 'define' file). I also know that the slave is not doing anything in this time when the address is being transmitted. Scenario <5> is invalid as I have an AXI_IIC IP being the master transmitter.

Any ideas as to why this NACK is happening?

Thanks for you patience in reading through this!

 

[shaiko]

Did you check that the slave is powered on?
Did you try to measure the signals with an oscilloscope?

 

[dpaul]

Did you check that the slave is powered on?
Did you try to measure the signals with an oscilloscope?

Did you see that I have a SIMULATION screen-shot attached?
Did you see that in the screen-shot that the IIC slave (i2c_s0) signals clk, reset and other signals are having some definite values?
Did you see in the screen-shot that the IIC slave signals CurrState_* and NextState_* are changing values?

Please explain why would I or anyone want to measure signals using an oscilloscope for a simulation only model!:?:

 

[FvM]

There is quite often confusion how to read I²C addresses, if e.g. 0x34 is the 8 bit number sent as first byte, or the number formed by the upper 7 bits.

The best way to find out what's happening is to look into the slave logic, e.g. in a simulation.

 

[dpaul]

Well 0x34 breaks down to 0011 0100. As per the UM10204 spec, Pg.13, bit 1-7 of the slave address is transmitted after the start condition, with the MSB being the 1st tx. bit. Bit 0 determines the direction bit (R/W). Since I see on the SDA line, 00110100, so this is the 7bit slave address 0011010 and bit0 = 0 which indicates a write request to the slave. After this comes the NACK and then the stop condition. Upto this I can clearly see in my simulation!
Since I have configured the AXI IIC Xilinx IP in the 'Dynamic Mode' so I expected that repeated START to be occurring on the SDA. But I don't see this. Maybe this repeated Start has something to do with the NACK. It could be that only if an ACK comes, then only the master proceeds with repeated Start to tx. other bytes from the transmit fifo.

 

[shaiko]

Perhaps the Opencores I2C IP doesn't have its control signals set to the correct levels (resets, enables, etc...).
Also, maybe it's configured in a way that prevents it from answering to a write request.

 

[FvM]

I keep my comment that you should look into the slave logic with debugging or simulation tools to see why the slave isn't responding, Repeated start shouldn't be normally a problem.

 

[Ashish Agrawal]

Are you sure that slave device address in i2cSlave_define.v is 8 bit not 7 bit ? If its 7 bit 7'h34 then in your c-code the command should be

// Set start bit, device address and write access
AXI_IIC_TX_FIFO_S0 = 0x168; // Address of the slave device

 

[KlausST]

Hi,

I wonder about startstop detect.

0 seems to be idle
1 seems to be started

Why it changes state after transmitting the 8 address bits and before the ACK bit?
It seems to be idle .... during ACK

Is this behaviour correct?

Klaus

 

[FvM]

You would need to look into the slave code to understand what the apparently multibit startstop detect state means.

I think it's asking a bit too much to expect Edaboard members to download the slave code and decode the simulator output, particularly when it's only partly readable. Some work should be done by the original poster.

But I assume you'll get the answer why the slave isn't responding quite easily.

 

[dpaul]

Hello FvM,

In none of my posts did I request any EDA board member to download the slave code and look into it. That is out of scope and difficult, I understand that. I did the top level connectivity and hence I have to debug it.
Why I posted such a comprehensive explanation was to get an idea about the region/area I should be looking into for a faster debugging.

@others: I will keep you suggestions in mind.

Thanks to all those who replied.