Resetting a 'hung' I2C slave device using NI-845x driver software

[AlanKnowler]

Do the NI-845x drivers have the capability recognise whether an I2C slave device has 'hung'? If so, will the NI driver automatically initiate a device reset?

If not can this be implented using the NI-845x I2C drivers?

This is one of many examples that a quick web search uncovered.

Thanks

Alan

(.......I'm putting some code together before we have any hardware - not even the NI-8451 module yet !).

[Alex.T]

Hi Alan,

I've looked over the 845x drivers and I haven't managed to find anything that suggests that an internal device reset is implemented automatically for potentially unresponsive slaves. Although the USB-8451 can perform clock stretching, since the communication of data requires a hardware-buffered implementation I believe that there would need to be some software 'cleverness' to define whether the I2C device had become unresponsive. In this respect, I believe an implementation of software interpretation of what actually counts as an inactive device would be necessary. 

So, how could this be done?

The NI-845X VIs allow you to poll the state of a line from within code (NI-854X I2C Script DIO Read Line.vi). I would imagine that in a situation where you do get interrupted during the communication process, you could make use of this VI to detect whether SDA is being held low on new cycles of SCL, which would cause concern and suggest that the slave has become unresponsive. You could then perform a read on the acquired data so far, determine your current position in the communication process, then dispose of the faulty data. You could also choose whether or not to repeat the previous instruction in order to ensure all of the data is acquired appropriately.

A device locking up in this manner should be a rarity, and its cause generally should only be with respect to the I2C Master. This is commonly experienced with Microcontrollers as they generally have to implement a polling-based method of line detection and interpretation, so when they try to perform other operations 'concurrently' via interrupts, they can sometimes get lost. For this reason, it's important when developing the I2C interface architecture to be aware of when this kind of erroneous situation is entered - this is where the line state detection and cycle iteration can come into play. Luckily, LabVIEW is the I2C Master and therefore we can notify the software of when we go into these interrupted states.

Kind Regards,

[AlanKnowler]

Thanks Alex.