Solved it with a hint from Andy Kunz.  The problem arises due to the
emulator reading the SSPBUF when single stepping.  This automatically clears
the BF flag before your software has a chance to read it.  If you don't
single step, then the problem goes away, but it kinda makes the emulator
less then usefull in these situations.  I guess at least it shows that the
silicon used in the emulator works exactly as the production silicon.  The
RF Solutions web site indicates that Microchip were going to fix this.  I'll
have a go on the ICE2000 emulator tommorow and see if they did!

Regards

Mike

> -----Original Message-----
> From: Rigby-Jones, Michael [PAI01:4837:EXCH]
> Sent: Thursday, May 18, 2000 5:54 PM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      I2C Slave blues
>
> Just spent an afternoon trying to get my I2C slave code working on a
> 16C74.
> I'm nearly at the "bash head against wall" stage, and I've been using an
> emulator!  God help anyone who tries to develope this without one.  The
> code
> is written in Hitech C.  I have checked the generated code for anything
> suspicious.
>
> The problem:
>
> The manual states that wheh sending the slave address from thge master, on
> the falling edge of the eighth clock pulse the PIC will compare the
> address
> with that held in the SSPADD register and if it matches it will set the BF
> flag and move the received address into SSPBUF (as long as the WCOL and
> SSPOV bits are clear).  I have verified this with the emulator (ICEPIC2),
> single stepping through my master I2C code.  On the falling edge of the
> ninth clock, the SSP should set SSPIF, causing an interrupt if the
> relevent
> masks are enabled.  It does this, but on entering the ISR, I find that
> although SSPBUF still hold the address, the BF flag is now clear so my ISR
> code can't tell anything has arrived.
>