> I have project comming up which will need to be controlable via I2C.  This
> means using the SSP module as a I2C slave.  I remember people on the list
> saying that using the SSP module as an I2C slave was quite a tricky affair,
> the module being prone to lock-up if the master did not adhere 100% to the
> I2C spec, and with no easy way of recovery.

Mike, that may have been me.

The only ugly issue with the basic SPP (the BSSP, in the new
MicroChip docs) module is that it is not always possible to detect
when the Slave is locked up.  The secret to keeping it working is to
prevent the lockup to begin with.  It only happens in one case,
where the master tries to read more bytes from the slave than the
slave expects to send.  How can this happen?  Two ways: Either
there is a length byte in the message and it gets corrupted, or there
is some other logic error where the slave "thinks" its done but the
master does not.  For example, suppose the Slave expects to be
asked for 3 bytes, and the Master wants to read 4 bytes.

In this case, when the Master finishes clocking in the 3rd byte, it will
ACK, then want to clock in a 4th byte.  The SSP will be holding the
clock line low, waiting for the firmware to load the 4th byte to the
SSP.  If the firmware has happily gone off elsewhere, the bus will
stay locked.

What I did to prevent this is two-fold.  First, I settled on all pre-
arranged fixed length messages to prevent a corrupted length byte
ffrom causeing the problem.  This is a limitation, but its often OK.
Second, I made provision in the ISR so that if the SSP interrupts for
another byte, and the buffer is empty, it sends a dummy FF byte.
This unlocks the bus, and later message handling logic must detect
that the FF byte is trash if it happens.

I discovered the problem when I was simulating bus faults (with a
screwdriver, if I recall correctly!)  Once the SSP was locked, I could
not get it out of that mode without sending a dummy byte or doing a
device reset.  I tried turning the SSP off, whihc clears the bus, but
when I re-enabled it, it comes right back into the locked up state.  I
have since found out that if you set the SSP OFF, then clear the
control bits, then turn it back on, you can get it unlocked.  IF you
can detect the error.

> Is this the case and if so was this just for the earlier devices or does it
> affect all SSP modules?  I'd also like to know if anyone has used the I2C
> slave through Hitech C with success.

Yes.  That's what I'm using.  With careful attention to detail in the
ISR (or support code) and with fixed length messages, its been very
stable.  And it is SO nice to have a party line that I can add to in the
future without adding hardware to existing parties  Its a network of 5
PICs and two other peripherals (RTC and EEPROM) and they all
play nicely together.

Read the SSP section of the datasheet and the Reference Manual
carefully and you should have it.

If you have any specific questions, I can try to help.

Regards,

Barry.
------------
Barry King, KA1NLH
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
Hinesburg, Vermont, USA
www.nrgsystems.com