I2C slave: detecting a NACK.

Fred Flintstone · Guest

I searched through the forum and found a post by Paolo Minazzi that describes the exact same problem i'm having with the I2C slave, but nobody replied with an answer.
I'm using a 16F88 as the slave with my own I2C code (based on the CCS examples). The problem is detecting when the NACK from the master is sent. I have too tried to use "ack = i2c_write(data);" in the slave but it always returns '0' (ACK) regardless of whether an ACK or NACK was sent from the master.
The other problem i'm having is also the same - when the master communicates with a NACK on the read from the slave, the interrupt in the slave triggers twice (causing code to execute that shouldn't resulting in buffers getting out of sync). If I could detect the difference between an ACK and a NACK in the slave, then I would be able to work around this 'double triggering', but as it stands I can't!

Any ideas?

Regards, Dave.

The original post:

Ttelmah · Guest

I was going to post to the other thread, but it seems to have disappeared....
I wrote an I2C slave, some time ago, which runs fine. However it 'predates' the I2C_ISR_STATE function, and reflected problems I have always had with the CCS I2C functions. My code was written for the 16Fxx6 chips, dirctly from the Microchip application note.
Now the extra interrupt, is both correct, and normal!. What should happen, is when the byte you have just _sent_, is complete, and the master responds with the ACK/NACK, another interrupt occurs. The behaviour is problematic, because, first the I2C write function waits for the byte to transfer - it shouldn't - instead you should just write the byte to the SSPBUF register, and secondly, because this next interrupt, needs to detect that there is now a NACK cycle. The 'NACK' cycle, is marked by the R/W bit being cleared.
So, I'd suggest, writing data directly to SSPBUFF (and read it as well), and then at the start of the handler code, either work out what I2C_ISR_STATE will return for a NACK, or look for this specific bit pattern on the processor registers.

Best Wishes

Fred Flintstone · Guest

Thanks Ttelmah! As usual you save the day! I've spent days trying to figure this out, and with your suggestion of looking at the R/W bit in SSPSTAT it all works correctly!
I found that I2C_ISR_STATE just increments normally on the second 'NACK' cycle so I couldn't use that. After digging out the 16F88 datasheet and messing with a logic analyser, all I had to do was to add the following lines:

Ttelmah · Guest

Yes. Agree about 1000%...
The functions are 'fine', for simple 'mainline' I2C, but really don't work very well at all for interrupt driven code.
It looked very helpful, when they added I2C_ISR_STATE, but if you compare it with the application note from MicroChip, it 'misses' seperating the NACK state, which is a pain.
The same is true of the SSP routines.

Best Wishes

Ttelmah · Guest

I'll see if I can find the old code, tomorrow.
I'd suspect the 'lockup', is something like SSPOV getting set (which the standard code does not handle).

Best Wishes

Ttelmah · Guest

Ok. I have just retyped the core, since what I had, was more complex (included setting the address from a write etc..). Have tried to add 18 support (no guarantees...).

Eugeneo · Joined: 30 Aug 2005 Posts: 155 Location: Calgary, AB

I've had the same lockup problem using a the f819 (almost the same as the f88). I had to read the spi register twice to clear the error.

Fred Flintstone · Guest

Thanks for the code Ttelmah. It will certainly come in handy.

As for the 'lockup' I described, i've now done some more testing and found that lots of writes to any of the portB pins causes the I2C interrupt to fail to fire (most of the time) after the initial interrupt and write that first addresses the slave. i.e. attempts at writing or reading the actual data does not result in any further interrupts.

The simplest code i've found to have this problem with is as follows:

Fred Flintstone · Guest

Could you elaborate on that a bit more Eugeno. What was the code you actually used to read the spi register twice?

Thanks.

Ttelmah · Guest

I do still wonder about SSPOV. The thing is, that the internal hardware is not limited to the I2C rate in use, and the receiver shift register, can trigger off really high frequency signals on the clock line If after a character is 'read' at the start of the interrupt handler, a second character is seen as arriving, before the interrupt routine exits, then the interrupt flag will get set, but will then be cleared, when the handler exits, and the code will have 'missed' servicing this. This will then give a SSPOV, and the interrupt handler will stop working.
I tend to suspect that something is triggering 'noise' on a line somewhere when you do the I/O...
Now, the 'best' way round this, is the same trick used in RS232 interrupt handlers, to cope with high data rates. If you modify the interrupt code as follows:

Fred Flintstone · Guest

You're spot on again Ttelmah. As soon as I read 'noise on the line' the first thing I did was to put a 100nF capacitor on the clock line to ground, and it cured the problem instantly. The I2C now communicates without a hitch from what I can see. I will get the scope on it later to see make sure the clock isn't distorting too much, plus I will also try to implement your solution just to be safe.
Such a simple problem but it just didn't spring to mind. Silly me - I should have known better.
Sorry to have wasted your time!

Thanks.

Paolo · Guest

Take a look at Application Note 734 that explain the solution of the problem.

Regards,
Paolo Minazzi