Cannot ACK/NACK I2C data byte based on contents

[lpcware]

Content originally posted in LPCWare by xlnt on Wed Jun 13 04:24:52 MST 2012
The following question holds for the I2C controller found in the various LPCxxxx devices. I found consistent information for LPC17xx and LPC43xx, but I think it will also hold for other devices.

According to the LPC43xx user manual, in master/(addressed) slave receiver mode, the Assert Acknowledge (AA) flag is used to acknowledge or not-acknowledge each byte received from another device on the bus:

LPC4350/30/20/10 User manual, Rev. 3.1
http://www.nxp.com/documents/user_manual/UM10503.pdf
Page 1028:

> AA is the Assert Acknowledge Flag. When set to 1, an acknowledge
> (low level to SDA) will be returned during the acknowledge clock
> pulse on the SCL line on the following situations:
>
> ...
> 3. A data byte has been received while the I2C is in the master
>    receiver mode.
> 4. A data byte has been received while the I2C is in the addressed
>    slave receiver mode
>
> The AA bit can be cleared by writing 1 to the AAC bit in the CONCLR
> register. When AA is 0, a not-acknowledge (HIGH level to SDA) will
> be returned during the acknowledge clock pulse on the SCL line on
> the following situations:
>
> 1. A data byte has been received while the I2C is in the master
>    receiver mode.
> 2. A data byte has been received while the I2C is in the addressed
>    slave receiver mode.

However, AA must be set prior to reception of the byte. This seems to be confirmed in Table 970 (master receiver mode) and Table 973 (slave receiver mode). E.g. Status code 0x40 in Table 970:

When AA is set to 0, the next (first) data byte will be received and NACK is returned.
When AA is set to 1, the next (first) data byte will be received and ACK is returned.

From this I conclude that a data byte cannot be acknowledged/not-acknowledged based on its value. I.e. it is automatically acknowledged/not-acknowledged based on AA.

It also means that the I2C controller inside LPCxxxx devices cannot be used to conform to the full I2C bus specification which specifies that a receiver can generate a NACK when it received data that it does not understand:

I2C-bus specification and user manual
http://www.nxp.com/documents/user_manual/UM10204.pdf
Page 10:

> The acknowledge takes place after every byte. The acknowledge bit
> allows the receiver to signal the transmitter that the byte was
> successfully received and another byte may be sent.
>
>...
>
> There are five conditions that lead to the generation of a NACK:
>
>...
> 3. During the transfer, the receiver gets data or commands that
> it does not understand.

Off course when data is received that cannot be understood, the next byte can be not-acknowledged, but this doesn’t hold for the last byte of a transmission.

So my question is:

Is the previous conclusion true, or do I misinterpret the user manual and is it possible to acknowledge/not-acknowledge a data byte based on its value?

[lpcware]

Content originally posted in LPCWare by noahk on Sat Nov 17 23:25:06 MST 2012
Hi xlnt,

The just released LPC800 family has a new I2C module that is capable of receiving the data and then choosing whether to ACK/NACK to the master. This allows for full SMBus support.

Check out the user manual:
http://www.nxp.com/documents/user_manual/UM10601.pdf
Chapter 16: LPC800 I2C-bus interface

Noah

[lpcware]

Content originally posted in LPCWare by DiligentMinds.com on Fri Aug 24 16:26:11 MST 2012
The I2C ACK/NAK is for byte-level acknowledgement (in the "link layer" so to speak).  The higher-level protocols (as you stated) use some kind of check-sum or CRC at the end of the packet.  In this case, the entire packet has already been transmitted, and there is nothing to tell the link-layer (hardware) transmitter that the message was not received or understood.  I2C hardware works on a byte-by-byte basis, and it has no knowledge of a "packet".  As already stated, error recovery happens at a higher layer in the stack, and the "ACK" or "NAK" that the higher layer sends to the transmitting node's higher-layer is not the same thing as an "ACK" or "NAK" that is sent by the hardware receiver to the hardware transmitter if a byte was (for some reason) not accepted.  Just because the writer of the I2C low-level hardware protocol and the writer of the higher-level software protocol both decided to use the name "ACK" and "NAK", does not necessarily mean that they are the same thing.

[begin rant]
BTW-- As a side issue, [IMHO] packet-based protocols should never "NAK"-- if there is an error in the packet, just throw the bad packet into the "bit bucket", and don't "ACK", then the sender will time out and will send the packet again with the same sequence number-- this works much better than any "ACK/NAK" protocol, which can end up in a never-ending cascade of ACK's and NAK's ad nauseum...  (Just Sayin'...)
[end rant]

[lpcware]

Content originally posted in LPCWare by xlnt on Thu Jun 14 03:40:08 MST 2012
Thank you for your reply.

Actually, I will be using a higher level protocol, i.e. SMBus.

SMBus supports packet error checking by appending a CRC-8 checksum as the last byte in a transfer. Now, because the ACK/NACK cannot be generated based on byte contents, it is not possible to (directly) signal a transmitter that the transfer failed if the checksum is wrong.

[lpcware]

Content originally posted in LPCWare by atomicdog on Wed Jun 13 10:33:54 MST 2012
[collapse]From this I conclude that a data byte cannot be acknowledged/not-acknowledged based on its value. I.e. it is automatically acknowledged/not-acknowledged based on AA.[/collapse]

This is correct.

[collapse]It also means that the I2C controller inside LPCxxxx devices cannot be used to conform to the full I2C bus specification which specifies that a receiver can generate a NACK when it received data that it does not understand:[/collapse]


I think your reading too much into it. The spec doesn't say that a specific bytes content can be NACK'd. I2C is a low level hardware protocol specification. Byte content type info is normally taken care of in a higher level protocol like IPMI or PMBus. I think #3 is just saying the transaction can be terminated early not that it can be terminated at an exact and specific place.