I am using an MKL05Z as a slave I2C device with the PE code managing the interface. While I have managed to get the solution fully working I have observed some behavior on the SDA line that I had to work around. Returning back to this issue it seems to be a very non-standard behavior.
When the host sends the Address byte to the MKL05, all is OK up to the ACK. I do get the ACK and the address byte is properly handled by the I2C code, but the SDA line is held low by the MKL for some significant period of time after the falling edge of the 9th clock pulse. I have tried different core and bus clocks. At 12MHz/6MHz Core/Bus the SDA hold time is about 16uS. Bumping both up to 24MHz this drops to 7.3uS. The I2C block is being clocked at 6MHz.
Does the I2C IP block require the CPU to issue and terminate the ACK? Even so, I seem to get the ack very quickly but it takes a long time for it to go away.
The problem this causes is that the I2C master has no idea this is occurring and will start the next byte. This byte is corrupted because the MKL is holding SDA low and is further, not ready to clock in the data bits. The workaround is for the master to wait for SDA to go high after each transfer. It does solve the problem and I can do it with my bit-bang master, but a normal hardware master really can't do this.
Has anyone else seen this?