Hi Dmitry (Kiryashov)

Thank you for writing. In response:
1. It's not an undesired interrupt after the I2C byte is received.
   The signals lock low within the first interrupt, immediately after sending
   the data byte.
   When they are stuck low, no I2C traffic can occur, so there are no further
   interrupts from the SSP either.

2. I'm aware of the Read-Modify-Write CPU access cycle effects.
   I can see how this could cause confusion in byte operations, but not single
 bits.
   Surely Microchip can make a chip where a one-bit operation only affects one
 bit?

   I don't think this is the problem because
   a) the problem occurs with or without my bit-twiddling code fragments trying
      to release the signals into hi-z.
   b) the registers indicate the signals should be hi-z.

I've just had a call from steve.diaper@microchip.com who is a general microchip
 FAE (Field Apps Eng,
Scandinavian area) directly employed by Microchip. He spoke to a chap called
 Robert in the USA who says that he
has seen I2C slaves working in read and write directions. So it IS possible.
 They say people have two common
problems with I2C.

1. Interrupt bits: SSPIF and SSPIE are same bit number in different banks.
   If you slip up on the data-page switching, can disable interrupts which can
 lock signals low.

2: The problem with read-modify-write and bit operations, as you said.
   I said: "You're telling me Microchip have made a chip where a one-bit
 operation
   affects more than one bit, and affects the other bits in bizzare ways? That's
 appalling!"
   Response: "Yeah, really sucks, doesn't it?"

Right, I'm going bug hunting. I'll be back.


Joke: What is 1km long, has thousands of legs, teeth, eyes, and eats cabbage?

Clue: It's not a Chernobyl caterpillar.













Answer: The queue at a Polish butcher's shop.