> The hardware module is better, but there are still a few pitfalls. We just
> ran into a condition in a Pic 16C77 where the SCLK is held low in the
> hardware slave RECEIVE mode.  In the transmit mode, the Pic slave hardware
> holds the clock low to give time to retrieve the data to be transmitted, but
> no such feature is needed or specified for the receive mode.

I2C spec allows a slave reciever to use clock stretching to slow down
the master, by holding SCL low.

BUT I don't see that this facility is supposed to be used by the
16C76 (which I use) nor presumably the '77 (same I2C hardware,
AFAIK).

> We think that the problem is caused by a combination of getting a succeeding t
ransaction
> byte piling on top of one in SSPBUF, causing an overflow.

An overflow into the SSP as slave reciever will cause the SSP to not
generate the -ACK pulse, but it is not supposed to lock SCL low.
(according to the specs)

> Two questions:
> 1. Has anyone run across this problem? and what exactly causes it
> (So we can stay out of those places.) We have a fix, but I really
> want to understand the mechanism.
Not exactly.  I had (have, its back! ) a lot of trouble with slave
TRANSMIT synch, where the SSP thinks there is another byte to send,
(I overran the transmitter and my "last" send byte got lost).  The
SSP is holding SCL low waiting for my code to write to SSPBUF.

The only way to stop the slave transmitter is to for the master to
not -ACK on its last byte (which is the usual I2C termination).  If
the master does generate -ACK, (or you get a fault that reads as
high) you HAVE to send another data byte.  Just setting CKP won't
cure it, there is no way to unlock SCL, short of a device reset.

> 2. Is there a less drastic way of curing the problem?
>
Once it's hung like this (which could happen in a noise induced
bus fault, I think) I have to write dummy bytes to the SSP under some
circumstances to recover.  Cycling the SSP off and back on DOESN'T
unlock it from this state.  Believe it or not.  Very ugly.

Loading a dummy byte into the SSPBUF, then setting CKP, then cycling
the SSP should work.  I hope.   I'm working on this now.  Anyone else
have any better ideas?  I'd love to hear them.

------------
Barry King, KA1NLH
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
Hinesburg, Vermont, USA
barry@nrgsystems.com
"The witty saying has been deleted due to limited EPROM space"