Does uTasker support a way to detect that I2C bus communication has stopped?

[tdrobnak]

A recent problem was identified on the I2C bus with uTasker as the master.  An I2C RFID device was causing the SCL line to not go low enough in voltage to be detected by the other slave devices.  A start condition could be sent, but the slave devices could not detect it because of SCL.  Does the Kinetis (KE15Z) version of the uTasker I2C driver support a way to detect that the I2C bus has failed to communicate.  I found an earlier message, https://www.utasker.com/forum/index.php?topic=872.msg3822#msg3822, on this forum that said there was a MASTER_TX_DATA_NOT_ACKED case for the LPC device driver that would detect that the slave was not able to acknowledge the message.  I could not find that same MASTER_TX_DATA_NOT_ACKED case in the Kinetis I2C uTasker source code.  Does anyone know of an already programmed way to detect this situation for uTasker's Kinetis I2C driver?

Thank you.

[mark]

Hi

As mentioned in the referenced thread all I2C transfers are completed, even if slaves don't respond - this avoids a non-responsive slave from disrupting the overall operation and it is assumed that data read form slaves (which will be always 0xff in such a situation) would be an indication of a HW issue.

For the Kinetis there are no methods built into the driver that specifically check and avert of slaves Nacking data.

If it is a problem that needs to be detected once to see whether the HW is Ok or not it may be suitable to read expected data from the slave device and decide whether all is Ok or whether there is a problem based on the data read back (assuming a non-operating slave can be detected by the data that it returns).

If it is an intermittent problem that needs to be detected during use it may be necessary to add such a method, which - in the case of the LPI2C in the KE15Z - means checking LPI2Cx_MSR for the LPI2C_MSR_NDF flag, which indicates that the slave Nacked (I haven't tested the exact behavior but I understand that this is the flag indicating the fact, which needs to be written with '1' to clear it again). The question is however how best to react to such detection since it may be best to still let transfers complete to avoid general disruption. In the simplest case it could be to detect a global flag to indicate that it was detected or send an interrupt event to a task that then decides what needs to be done.

The next question is what to do in such circumstances - if it is a HW issue the code can only really signal that there is a problem so that the HW can be worked on since repeating and so on will presumably just result in the same failure (?)

Regards

Mark

[tdrobnak]

Thank you, Mark for your explanation.  My thought on a solution is in the same line of thinking as yours.  Since I posted this message, I have modified the high level application design to include a acknowledge flag whenever there is a request for information from the slave.  If the slave does not acknowledge within the 1 second software interrupt time, a retry with that same message will occur up to 5 times.  If after 5 times (5 seconds), there is no response from the slave, the application will generate a shutdown error.  In this way, I can be certain that there is a communication problem with any particular slave, and the communication problem is not just missing one acknowledge (maybe due to electrical noise in the environment).  I want to make the shutdown of the unit more I2C noise immune.

[mark]

Hi

Yes, transfer errors due to noise or intermittent interference can never be excluded (also when slaves acknowledge) and it makes sense that the application layer is involved with ensuring that such things don't lead to erroneous behavior.

Some I2C devices, such as temperature and humidity sensors include CRCs in the data that they return in order to help identify bad values rather than blindly using what is received.
Some times the application may do a plausibility check (eg. if the temperature falls from 20°C to 0°C in one second it may prefer to filter the value rather than treat it as a valid result).
But in any case the application should always be aware of the fact that something may go wrong (as well as a slave device be missing or damaged) and consider being able to detected and handle such permanent and intermittent issues in a suitable fashion.

Regards

Mark