I am pulling my hair out trying to get a PIC MCU (18F46J50) to communicate with a CDCE913. The I2C bus transfers appear to be working (looking at a scope), but the TI device isn't responding functionally as it should. It appears to be stuck in the default power-up configuration, which is passing the input crystal frequency directly to all three outputs. The outputs are always enabled via a pull-up on the S0 control pin.
My initialization software appears to be sending the correct single byte writes to the part to change the configuration. The part is responding with ACK bits to the incoming data stream. However no configuration changes are being registered. I have added a sequence of register readbacks for debug and to attempt to verify the setup. The device appears to be responding with 0x07 data value for all register offsets requested. Again the I2C protocol and ACK responses appear to be correct.
I am currently delving into the timing details of the PIC I2C output as I have uncovered some peculiar software "hangs" when varying the baud rate and clk slew setup slightly during my debug efforts. I am running the interface at standard 100KHz speed and the SCL/SDA waveforms look correct to me on the scope. Does anyone have any ideas as to what is causing the CDCE913 to refuse or ignore the configuration commands?
During initial software development, I thought that I may have accidentally achieved block writes that wrote unintentional data into unknown register locations or offsets of the prototype card I'm using for development. However, I have since tested the now "correct looking" I2C code on a fresh previously unpowered set of hardware and gotten the same response from the clock chip. Other than continuing debug of Microchip's SSP interface behaviors, I am at loss to explain the CDCE913 behavior.
Thanks in advance for any insights or suggestions.
