I2C - Master generates NAK on last byte of read from slave - why?
Daniel Quinz
The I2C spec specifies that when a master is performing a read from a
slave, the master must not acknowledge the last byte before issuing a
stop condition (ie: it NAKs rather than ACKs).
In contrast, during a write, the slave is supposed to generate an
acknowledge for each byte received (if it can correctly receive the
byte) until it receives a stop condition.
It is not clear to me why the master must not acknowledge reception of
the last byte read even thought this
byte was received correctly. Should'nt the master acknowledge the last
byte, indicating it was received okay, then issue a stop to signal it's
done?
I have seen code which generates ACKs for all bytes (as master) and the
peripheral chips seem to work fine, but I am not comfortable doing this
when the spec says otherwise.
It is not obvious to me why the spec would insist on this behaviour.
Any comments, insights, musings, etc. would be welcome.
Regards,
Daniel Quinz, P. Eng.
Micronetics CES
e-mail: da...@micronetics-ces.com
Myron Tuttle
the NAK it does not load the next byte into its transmit buffer but waits
for a STOP. Some microcontrollers (i.e. 8xC652) have hardware I2C
interfaces and don't work unless a NAK is sent on the last byte.
The NAK tells the slave transmitter to let go of control of the SDA line so
that the master can send a STOP. If the NAK was not sent, the slave
transmitter would try to send another byte (bit) while the master was trying
to send the STOP. The NAK lets the master take control of SDA to send the
STOP.
I hope this helps.
Myron Tuttle
myron_...@hp.com
mtu...@slip.net
Daniel Quinz wrote in message <36BB60...@micronetics-ces.com>...
>I have a question that perhaps someone here might have an answer to.
>
>The I2C spec specifies that when a master is performing a read from a
>slave, the master must not acknowledge the last byte before issuing a
>stop condition (ie: it NAKs rather than ACKs).
>.....
Paul Bealing
EEPROM and Dallas DS1621.
I was asking myself the same question. I thought it more logical to ACK the
last byte then issue STOP.
I found a pdf file detailing the spec on the Phillips web site.
The ACK/NAK is in the 9th bit position. Following the 8 bits of the last
byte I do not send the 9th bit at all, but force a stop condition. It seems
to work fine. The data sheet does show the 9th bit before the stop. The
slave sees the data line high, so stop is close enough to NAK.
The EEPROM data sheet says that the device looks for a low (ACK) during the
9th bit position. If not low, it terminates the operation.
Some slaves might not like the missing 9th bit, I think I'll try a NAK after
the last byte.
Regards
Paul Bealing
Daniel Quinz wrote in message <36BB60...@micronetics-ces.com>...
>I have a question that perhaps someone here might have an answer to.
>
>The I2C spec specifies that when a master is performing a read from a
>slave, the master must not acknowledge the last byte before issuing a
>stop condition (ie: it NAKs rather than ACKs).
>
>In contrast, during a write, the slave is supposed to generate an
>acknowledge for each byte received (if it can correctly receive the
>byte) until it receives a stop condition.
>
>It is not clear to me why the master must not acknowledge reception of
>the last byte read even thought this
>byte was received correctly. Should'nt the master acknowledge the last
>byte, indicating it was received okay, then issue a stop to signal it's
>done?
>
>I have seen code which generates ACKs for all bytes (as master) and the
>peripheral chips seem to work fine, but I am not comfortable doing this
>when the spec says otherwise.
>
>It is not obvious to me why the spec would insist on this behaviour.
>
>Any comments, insights, musings, etc. would be welcome.
>
Wil Taphoorn
> It is not clear to me why the master must not acknowledge reception of
> the last byte read even thought this byte was received correctly.
> Should'nt the master acknowledge the last byte, indicating it was
> received okay, then issue a stop to signal it's done?
No, ACK means "send more" for the slave and it will do so. If the next
bit of that transmission is a zero then the master is unable to issue
a STOP condition (SDA high during SCL high).
The only way to get the slave off-line is issuing NAK at the end of the
final byte.
Olav Woelfelschneider
MT> The NAK tells the slave transmitter to let go of control of the SDA line so
MT> that the master can send a STOP. If the NAK was not sent, the slave
MT> transmitter would try to send another byte (bit) while the master was trying
MT> to send the STOP. The NAK lets the master take control of SDA to send the
MT> STOP.
Yeah, that's it. To make it more clear: If you ACK the last byte, the slave
prepares to send another byte by putting it's first bit on SDA. If this bit
is low, the SDA line is clogged and the master is not able to send a stop.
Learned that the hard way.
--
Olav "Mac" Wölfelschneider wo...@cardware.de
PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
Mer muß doch nur emol e bissje nochdenke. -- Mundstuhl
Daniel Quinz
>
> You have to consider what the slave transmitter is doing. When it receices
> the NAK it does not load the next byte into its transmit buffer but waits
> for a STOP. Some microcontrollers (i.e. 8xC652) have hardware I2C
> interfaces and don't work unless a NAK is sent on the last byte.
Thanks. I was re-reading the specs on the PIC16C73 and I noticed a
similar desription of events.
Regards,
Dan
>
> The NAK tells the slave transmitter to let go of control of the SDA line so
> that the master can send a STOP. If the NAK was not sent, the slave
> transmitter would try to send another byte (bit) while the master was trying
> to send the STOP. The NAK lets the master take control of SDA to send the
Tony Williams
Paul Bealing <pa...@pmb.co.nz> wrote:
> I found a pdf file detailing the spec on the Phillips web site.
Email only, not posted in the newsgroup.
I was following this thread because of an impending
need to implement some I2C eeprom. From the Microchip
data sheets I *thought* I had a grasp of it. But......
Can you give a URL for that website where you found
that pdf file?
Thanks.
--
Tony Williams.
Daniel Quinz
<snip>
>
> Can you give a URL for that website where you found
> that pdf file?
>
> Thanks.
Hi Tony.
You can get the pdf file from philips website at the following address:
http://www-us2.semiconductors.philips.com/i2c/facts/#specification
Regards,
Daniel Quinz, P. Eng.
Micronetics CES
Tony Williams
> > I found a pdf file detailing the spec on the Phillips web site.
> Email only, not posted in the newsgroup.
And guess which fool hit the wrong bloody key
to send it. :(
--
Tony Williams.
Tony Williams
Daniel Quinz <da...@micronetics-ces.com> wrote:
> Hi Tony.
> You can get the pdf file from philips website at the following address:
> http://www-us2.semiconductors.philips.com/i2c/facts/#specification
Got it thanks, 24 pages of good stuff.
--
Tony Williams.
Tony Williams
Myron Tuttle <mtu...@slip.net> wrote:
> You have to consider what the slave transmitter is doing.
> When it receices the NAK it does not load the next byte into
> its transmit buffer but waits for a STOP. Some microcontrollers
> (i.e. 8xC652) have hardware I2C interfaces and don't work unless
> to let go of control of the SDA line so that the master can send a
> STOP. If the NAK was not sent, the slave transmitter would try to
> send another byte (bit) while the master was trying to send the STOP.
> The NAK lets the master take control of SDA to send the STOP.
I wonder if I could describe the sequence brick-by-brick,
to see if my interpretation of the Phillips I2C data
sheet is correct.......
We are talking master-receiver, the master is generating
SCL as a series of low-highs, low-highs, etc. During
each low the slave sets SDA to the req'd state, and the
master reads that state during the highs.
At the end of bit8, the master sets SCL low, and presumably
this causes the slave to release SDA. During the low period
of bit9 the master can pull down SDA to ACK, or leave it
high to NACK. During the high period of bit9 the slave
reads which way was set.
Now, a STOP is defined as a low-high transition of SDA
whilst SCL is high.
But, and here's where I staggered, to NACK during bit9
it had to set SDA high, so SDA is now in the wrong state
to do a simple low-high transition.
The master has to drop SCL (therefore starting a bit10),
and, during that low, set SDA low, then raise SCL, then
raise SDA. (with req'd timings of course)
I cannot actually see any other way doing a STOP.
Is this correct?
--
Tony Williams.
Myron Tuttle
this point the slave lets go of control of SDA. Then the masster pulls SDA
low, lets SCL go back high, waits 5us and then lets SDA go high to generate
the STOP. Remember that the I2C bus can only assert a low. The highs are
generated by letting the pullup do it.
Tony Williams wrote in message <48d21ef...@ledelec.demon.co.uk>...
Tony Williams
Myron Tuttle <mtu...@slip.net> wrote:
> That is correct. During the 9th bit the master sets SDA high
> for a NAK. At this point the slave lets go of control of SDA.
> Then the masster pulls SDA low, lets SCL go back high, waits
> 5us and then lets SDA go high to generate the STOP. Remember
> that the I2C bus can only assert a low. The highs are
> generated by letting the pullup do it.
Yes thank you. Useful things, newsgroups. :)
--
Tony Williams.
Tim Chantor
There are two reasons, one directly related to bus state:
1) After a read ACK, a device will prepare to shift out the next byte. If the first bit of this byte is a
zero, the device could drive the bus while the host is attempting to signal a stop condition. This
would only happen if the device drove the next bit shortly after the clock's rising edge (the edge
that latches the ACK/NAK) instead of waiting for the the next falling edge. Strictly speaking, this
is not a violation of the protocol since the device knows when it has received the ACK/NAK, and
driving opposite the host ACK/NAK for part of a clock phase is not an electrical collision given
the open-collector implementation of the drivers. So, the host must NAK to indicate to the device
'I do not want to hear from you anymore,' clearing the way for a STOP condition.
2) If a device implements auto-increment of register address (or sub-address) on read, ACK on
last read can cause the device to falsely advance its internal register address - all depending on
the device's specific implementation. Usually not a big deal since the next read transaction can
reassert the register address.
Tim Chantor
[potentially low] bit, this can still be a problem because a host often issues a falling clock edge after
the ACK/NAK phase in order to prep the data line for STOP. Imagine that, after ACK/NAK, clock
is high and data is high. A STOP needs to affect a data low-to-high transition while clock is high. If
the host were to simply bring data low and then back high, it would actually be signaling a repeat
START followed by STOP. So, it would need to being clock low, then data low, then clock high,
then data high in order to avoid the unintended repeat START. It is this additional clock low
transition that invites a new, potentially low, data bit to be driven onto the bus.
David Brown
> On Thursday, February 11, 1999 at 3:00:00 AM UTC-5, Tony Williams wrote:
Please look at the dates above.
While it is good that you want to help the poster with an answer, it is
unlikely that he has been sitting quietly waiting for help for the last
22 years.
If you want to join this Usenet group (and I hope you do - it's been a
bit slow in recent times), I recommend you use a real Usenet client and
server. Thunderbird is free, and works on any system, and
news.eternal-september.org is a free server (there are many other
clients and servers if you prefer). Usenet works far better with a
decent client rather than Google's broken "Groups" interface. But if
you do use Google Groups, check the data of the posts you reply to!