BenF:
It is not so however that TW_SR_GCALL_DATA_NACK and TW_SR_DATA_NACK are final states. The master will still issue a bus stop condition and the slave receiver will catch this (TW_SR_STOP), enable TWEA and so be ready to accept new requests. Without a final stop condition the bus will be considered busy and so no communication between any I2C devices on the bus could take place. Figure 21-16 in the datasheet shows how this is handled.
I attached a screen shot of the figure in question. I added two big red arrows pointing at the states I mean. Yes it is true that a STOP is sent, but the fact that a stop is sent does not imply that a TW_SR_STOP ($A0) is reported in TWSR. This is the case after $80/$90. In the $88/$98 case, there is no state reported. $88/$98 is the last thing you see in TWSR. This is what I mean with "Final state". Afterwards there is $F8, which means "No relevant state information available"
BenF:
If what you claim (no stop condition issued after data nack) is true, then there would also have been an issue with clearing TWEA for the buffer overflow condition in response to TW_SR_DATA_ACK (this is also what must happen for TW_SR_DATA_NACK to ever be called). This is however not the case as a stop condition will always follow.
Not always. As mentioned above, a TW_SR_STOP is seen in TWSR only in the cases where it is shown in the figure.
I made this change in my code and it works perfectly. The TW_SR_DATA_ACK is not affected by this change.
