I2C Slave: how to generate NAck ?

fadeout · Joined: 28 Jan 2004 Posts: 15

As you can see, who can remember (ref. old posts), I'm fighting (and loosing :( ) with I2C.

Now my HW seems to be ok. (if someone wants to know how just ask).

I'm not able to generate a NACK (not using built in functions) so questions:

1) Is true that I have to generate NACK at the last received byte? (source AN734 page 1)

2) How can I do this ?

Please help me: I'm getting mad with this project...

Guest · Posted: Tue Feb 24, 2004 5:31 pm

This is my understanding.
1) No. The slave hardware generates the ACK (low) or NACK (high) based on whether the byte has been handled or not. It's not a programming option in itself. See page 4 description of SSPOV bit function.

If the slave buffer is large enough for the number of bytes sent by the master or the bytes are just transferred to a port after address match then a NACK will not be generated on any of the received bytes.

HTH

fadeout · Joined: 28 Jan 2004 Posts: 15

That is was the way I worked until now.

But I can only do:

1) Master write: as many bytes as I want BUT I can't get the interrupt on the stop bit

2) Master read: my slave can only send one byte. Here I detect the stop bit (same interrupt handler).

I noticed that my problem is that in case (2) I can't understand why the slave (PIC) reads ACK/NACK with one clock before he should: from PC I have no time to put low the SDA Line. This is an error (I don't know why) but at this condition I clear detect the Stop condition.

Otherwise, in case (1), Master transmit as many byte as I want and always read ACK: here (there is no NACK) I can't get to stop condition.

So my actual experience and from AN734:

Guest · Posted: Wed Feb 25, 2004 5:12 pm

The quote and Figure 1 show an example of operations, not what happens automatically I think.
To make the hardware generate the NACK (or more correctly not generate the ACK by pulling SDA low) after the last byte received then it would be necessary to count the incoming bytes and not read the last two bytes as they come in.
Reading a byte from SSPBUF clears the BF bit, so if it is not read the SSPOV bit is set on the falling edge of the 8th bit on the next byte and then the NACK is generated on the 9th bit.
That is, there needs to be two bytes at the end that are not read immediately - the second last one could be read later by reading SSPBUF, the last one not readable.
I haven't tried this but it should work if you really want the master to see the NACK. Doesn't sound right, but that's the way I read the data sheet.

1) There is no interrupt on the slave when the master issues a start or a stop. The interrupt flag is only set when a byte is received and ACK is generated.
The bits in SSPSTAT only show which one was last detected by the hardware, S or P. If S was last detected then P last detected will be zero, and vice versa.
So in the isr you make sure the S was last detected by including the bit in the mask.

2) Sounds like a timing problem. The stop last detected on the slave should only occur if the master has done a stop.

fadeout · Joined: 28 Jan 2004 Posts: 15

Thank you guest. I agree with you for the "method" to not generate the ACK; I haven't tried it yet.
So am I think that I shuold have a timing problem but no way finding where.

I'm so despaired that I'm changing my comm protocol to read back from the slave only one byte at time....