Strange SDA behavior on MKL05Z part in slave mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Strange SDA behavior on MKL05Z part in slave mode

874 Views
DavidLundquist
Contributor I

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

Labels (1)
Tags (3)
0 Kudos
3 Replies

646 Views
DavidLundquist
Contributor I

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

0 Kudos

646 Views
vicentegomez
NXP TechSupport
NXP TechSupport

Hi, please let us know if your still need some help.

Regards

0 Kudos

646 Views
egoodii
Senior Contributor III

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.

0 Kudos