The problem turned out to be a bad connector on the logic analyzer. It is a 34-channel LA, but we tended to use just the first few channels over and over. Apparently the female jack for the SCL line, which accepts a pin like those on 0.1" headers, had become flaky. I should have realized it was something to do with the LA when I got the same results with the Bit Whacker.
I looked at the signals with a scope, and both the SCL and SDA were high when idle, and when low with the start protocol.
I picked a different set of channels on the LA, reconfigured the I2C interpreter to use those instead of the first two channels, and got a nicely interpreted I2C protocol.
Since your I2C works at 100Khz, but not 400 Khz, it is a good idea to look at the various factors that have an effect on timing.
1: Check that your slave board supports 400Khz.
2: Resistor values are too big.
When the timing is increased from 100k to 400k, the period of the clock drops from 10 us to 2.5 us.
This means that the rising edge of your data/clock signals has a significantly less amount of time to settle. the time taken is calculated as follows:
t = rc
the capacitance on the bus is usually constant and a property of each device. It sounds like you have these. Add them up.
The resistor values are the next variable. Since you have three in parallel, you need to add them using 1/Rt = 1/R1 + 1/R2 + 1/R3
and so on. You only need one resistor on the bus, so having three in parallel is going to lower the total resistance.
You can now calculate t using the above formula. If it is more than 300ns (just over 10% of your clock period at 400k), then the rise time is out of I2C spec. Here, table 5, page 32.
If you'd like to calculate the correct resistor value, you can re-arrange the above formula to get R=t/c
and work from there, where T is 300ns or less.
Best Answer
The most glaring omission is the fact that this is an OmniGraffle block diagram, not a schematic. A reasonable schematic would show all connections and components.
No it doesn't hurt it. I do it with SPI all the time which can be much, much faster than I2C. I don't see how you could mess that part up!
You need to eliminate acute angles to reduce acid traps for board etching. Otherwise I2C is SO SLOW that you can treat it as a wire on a PCB. You can't get anything long enough on a circuit board for stub lengths or termination to matter. It gets a little more iffy when you start taking it between PCBs and over cables though.
The only thing I see here that looks weird is the low-speed resistors in the main branch (4.7k) and the high-speed resistors in the child branches (2k). Usually you use a lower resistance pull-up when you're running at 400kHz and 4.7k when you're running at 100kHz.
Note: This is not a 'normal*' mux.. rather it is a 'branch selector' that can have many or no branches connected. Your control byte, defined as
is used to select the MOSFET switches individually
and you can turn on or off any branch arbitrarily.
*A normal mux would code to 001 -> 00000001, 010 -> 00000010, 011 -> 00000100...