K22 slave pulling I2C clock/data lines low when not sending/receiving

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

K22 slave pulling I2C clock/data lines low when not sending/receiving

Jump to solution
3,226 Views
kevinlfw
Contributor III

When my K22F device is plugged in, I immediately start communicating over I2C with the master via polled communication (versus interrupt driven) and everything works as expected.  When the job is done, every (1) second, the Master issues a read to the K22F slave.  If the slave doesn't write data (respond) to the master, the I2C clock and data line are pulled to low voltage signals and its the K22's fault.  My question is WHY and perhaps how do I prevent that.  Because of this, all other components on the I2C bus stop communicating because the signals are to low to be considered in a HIGH state.  Here is an image of the scope when the K22F slave is not responding:

20161103_155103.jpg

These signals are approximately 390mV.  This is the master issuing a read to address 10 (the K22F) and the slave not responding.  Under normal conditions and regular communication, the signals are 5V and there is no issues.  When the K22F slave is taken off the I2C bus, the signals go immediately back to 5V.  

I can currently work around this by having the K22F slave send data, but in the event we don't do this, the signals shouldn't be pulled down I would think.

So far I've tried enabling pull-ups on the I2C0_SCL and SDA lines, but that didn't help.  I've tried attaching physical pull-ups to the I2C0_SCL and SDA lines, that didn't work.  And lastly, I've set i2c_slave_user_config_t.slaveListening = true, and the line never goes low, but that breaks all the other code and will always send something out.  So, is my only option to constantly send out data with the K22F when I'm not sending any other data over the line?

Thanks,

Kevin

Labels (1)
0 Kudos
1 Solution
2,427 Views
egoodii
Senior Contributor III

Sorry, it is the definition of I2C that slaves must 'pull' the clock-line low to 'pace' a master when return-data is not immediately available.  And in ALL cases of microcontroller I2C slave implementations, they ALWAYS pull the clock-line low at every access as uC firmware must supply the return data 'after some time'.  Once you have initialized the K22F into I2C 'slave' mode, you are going to have to be sure that it is ALWAYS 'ready' to return data for I2C transactions addressed to it, else it will indeed permanently stall the whole I2C bus. If you don't want the K22F reacting to such transactions, you have to disable this slave mode (for at least those time periods).  Does your K22F respond to addressed transactions 'fully normally' when properly enabled?

View solution in original post

0 Kudos
3 Replies
2,428 Views
egoodii
Senior Contributor III

Sorry, it is the definition of I2C that slaves must 'pull' the clock-line low to 'pace' a master when return-data is not immediately available.  And in ALL cases of microcontroller I2C slave implementations, they ALWAYS pull the clock-line low at every access as uC firmware must supply the return data 'after some time'.  Once you have initialized the K22F into I2C 'slave' mode, you are going to have to be sure that it is ALWAYS 'ready' to return data for I2C transactions addressed to it, else it will indeed permanently stall the whole I2C bus. If you don't want the K22F reacting to such transactions, you have to disable this slave mode (for at least those time periods).  Does your K22F respond to addressed transactions 'fully normally' when properly enabled?

0 Kudos
2,427 Views
kevinlfw
Contributor III

Thanks egoodii‌.  The K22F didn't always respond to addressed transactions, so that was the problem I'd say.  Is it normal though, for the line to stay pulled down even when other devices are being addressed?   

Looking at the spec, is this an indication of what clock stretching is? 

0 Kudos
2,427 Views
egoodii
Senior Contributor III

Yes, this is an 'extreme example' of clock-stretching by a slave.

I'm not sure what you mean when you say 'K22F doesn't always respond to addressed transactions'.  If the K22F I2C peripheral is set in 'slave' mode with the proper address setting, I think we have to believe the hardware will ALWAYS respond to the matching address, and do so by pulling the two lines 'low', delivering an 'ACK' to the address-byte, but 'stopping' the clock to 'stretch' it until firmware can read or write the next byte.  Which is to say the 'rest' of any I2C 'response' is entirely up to firmware, and it MUST be in a mode to listen-to and sequence the rest of the transaction before it can be 'complete' to return the I2C bus to 'other transactions', including of course those addressed to 'others'.

You might also get some insight from:

https://community.nxp.com/thread/388619