NACK and ACK responses on I2c bus

Question

My recent project requires the use of i2c communication using a single master with multiple slaves. I know that with each data byte (actual data) sent by master,the slave responds with Nack\Ack(1,0). I am confused that how this Nack and ACK are interpreted. I searched the web but i didn't got clear picture about this. My understanding is something like this.

ACK- I have successfully received the data. Send me more data. NACK- I haven't received the data.Send again. Is this something like this or I am wrong. Please clarify and suggest the right answer.

Thanks Amit kumar

Freehanded

Answer 1

You really should read the I2C specification here, but briefly, there are two different cases to consider for ACK/NACK:

1. After sending the slave address: when the I2C master sends the address of the slave to talk to (including the read/write bit), a slave which recognizes its address sends an ACK. This tells the master that the slave it is trying to reach is actually on the bus. If no slave devices recognize the address, the result is a NACK. In this case, the master must abort the request as there is no one to talk to. This is not generally something that can be fixed by retrying.

2. Within a transfer: after the side reading a byte (master on a receive or slave on a send) receives a byte, it must send an ACK. The major exception is if the receiver is controlling the number of bytes sent, it must send a NACK after the last byte to be sent. For example, on a slave-to-master transfer, the master must send a NACK just before sending a STOP condition to end the transfer. (This is required by the spec.)

It may also be that the receiver can send a NACK if there is an error; I don't remember if this is allowed by the spec.

But the bottom line is that a NACK either indicates a fatal condition which cannot be retried or is simply an indication of the end of a transfer.

BTW, the case where a receiving device needs more time to process is never indicated by a NACK. Instead, a slave device either does "clock stretching" (or the master simply delays generating the clock) or it uses a higher-layer protocol to request retrying.

Edit 6/8/19: As pointed out by @DavidLedger, there are I2C flash devices that use NACK to indicate that the flash is internally busy (e.g. completing a write operation). I went back to the I2C standard (see above) and found the following:

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.

Therefore, these NACK conditions are valid per the standard.

Short delays, particularly within a single operation will normally use clock stretching but longer delays, particularly between operations, as well as invalid operations, my well produce a NACK.

Refusal

I believe some I2C EEPROM does respond with a NACK when it isn't ready. See AT34C02D-SSHM-T – Swivet

@DavidLedger Reading the datasheet, I see you are correct. After a write command, the device starts the internal write cycle(s) and the I2C interface is disabled and thus will not ACK until the cycles are completed. They suggest polling by repeating the next operation until an ACK is received. They also will NACK a write if the device is write protected. – Refusal

Hi, in case of master-reciever. Lets say master sent a NACK to the slave after slave sent some byte to him. What should be the slave response to that? should the slave leave the sda line so the sda line will stay high and that`s it? I mean if I want to check that the slave behave correctly.. what do I expect from him to do after master sent a nack? – Mutable

@Mutable Note case 5 in my answer above. This would signal that the master doesn’t want any more data. The next thing the slave should expect from the master is a STOP condition (or maybe a repeated START, I’m not sure). Anything else is undefined by the spec. If the master were to NACK and then continue clocking bytes in, the slave would be free to do just about anything. IMO, the slave could legally ignore the NACK and just look for the STOP. – Refusal

The link to the specification is broken and there are too many pending edits, so here is the specification I found: i2c2p.twibright.com/spec/i2c.pdf – Dispirit

Here I found UM10204.pdf. – Spectroscopy

I selected the link from @Velvel since it is linking to NXP although since it's a forum attachment, I'm concerned it might vanish too. I think it's still a better link than a 3rd party site. NXP sure left a lot bad links across the Internet! – Refusal

Answer 2

I2C Protocol starts with a start bit followed by the slave address (7 bit address + 1 bit for Read/Write). After sending the slave address Master releases the data bus(SDA line), put the line in high impedance state leaving it for slave to drive the line.

If address matches the slave address, slave pull the line low for the ACK. If the line is not pull low by any of the slave, then Master consider it as NACK and sends the Stop bit or repeated start bit in next clock pulse to terminate the or restart the communication.

Besides this the NACK is also sent whenever receiver is not able to communicate or understand the data.

NACK is also used by master (receiver) to terminate the read flow once it has all the data followed by stop bit.

Crocket