> Generally one would like to understand the failure mode, in
> order to ensure that you are not going to be bitten again later.

Yes, absolutely. I really got sucker-punched
 
> Could it be a silicon bug? e.g. divisor not providing the correct
> clocks in the F88. You would think slower would be better,
> but maybe there is some glicthyness in your lines

The supply is well-filtered, and at one stage the master-slave were
almost soldered together. I've looked at SCL and SDA and other
lines very very closely and find no noise. The F88s I have are all
the same batch, so I can't disprove a silicon bug

> A quick test would be to double your crystal frequency
> on one side, and then the other to see if it's an
> absolute time, or relative time (bit period vs Tcy) issue.

Master is running at 39.321MHz, slave at 8MHz internal. This is
how I envisioned them in production, so that's the environment I'd
like the I2C to work in, but your suggestion is worth pursuing to
gather more clues

> You're not sending continuous data streams are you?

No. The address polling is the longest activity. This is 18 bytes
separated by S/P, altogether taking just short of 2ms. Next
longest is address + 11 data to the slave, about 1ms

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist