All,
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?
Dave
One further piece of information. Increasing the bus and core clocks seems to reduce the SDA hold low after ACK time. Core/Bus combinations are:
Core/Bus
12MHz/6MHz => 15.8uS
24MHz/12MHz => 12.0uS
24MHz/24MHz/ => 7.3uS
Dave
Hi, please let us know if your still need some help.
Regards
Are you sure the issue is SDA hold, and not SCL hold-low? A slave holding the clock 'low' is a normal function of I2C, and is the mechanism by which ANY slave can 'pace' the master. ALL 'firmware involved' I2C slaves will have a 'response time' requirement, which is the time it will take from the end of the ACK period before firmware clears the receive-register and frees the hardware to receive another byte -- at which time the master would be released to clock it out. Naturally, the faster your core&bus run, the quicker this byte will be read-out. Unfortunately, this particular nuance of I2C links is 'not well supported', as many 'common' I2C parts (like memory chips) do not NEED this kind of pacing, given a completely hardware I2C slave interface.