TWI/TWIM bus probing / bus scanning

[Pascal Künzi]

Dear DevZone Team

To detect possible TWI slave devices connected on a TWI bus, we want to scan for device addresses and check if they are being acknowledged. 

In the twi_scanner example found within the nRF5 SDK, the scanning is solved by reading one byte from the desired address if it is ACK'ed.
Yet, we want to prevent reading or writing any additional data after checking the ACK of the address byte.

Against the product specification, we set the TWIM TXD.MAXCNT = 0 and then start the transmission with TASKS_STARTTX = 1.

• If the address is NACK'ed, EVENTS_ERROR is set and the transmission can be stopped. -> No slave device is available on this address.
• If the address is ACK'ed, no further data is sent but also no STOPPED or LASTTX event is generated. Nonetheless, a short timeout can be awaited before the transmission can be stopped. Since the EVENTS_ERROR is not set, one can assume that an ACK has been received. -> Slave device is available on this address. 

Is this a viable approach to implement TWI bus scanning or do you advise against this solution? If there is a solution adhering to the specification please let me know as well.

Thank you in advance!

Best regards,
Pascal

[Einar Thorsrud]

Hi Pascal,

Zero length read/writes are problematic. Doing like you write with a timeout before stopping may work, but I am not sure of potential side effecs. Generally, TWI/I2C bus scanning is performed for development purposes and you should expect that devices on the bus may be in a bad state afterwards. May I ask for the use case? What is the end goal? Could it be that it could be done in another way?

Br,

Einar

[Pascal Künzi]

Hi Einar

Thank you for your assessment!

We were asked for a generic TWI bus probing functionality that does not transmit or read additional data. Hence, I cannot give you a specific use case but would assume, that the possible target devices withstand the probing.

Nonetheless, I agree that there are TWI slave devices that may end up in a bad state. As a result, it will be necessary to verify that the probing is actually "supported" on the target devices before using it in production.

If you are unsure about the nRF's behavior in this situation, I rather not use my suggested approach. 
I would appreciate it if you could clarify or elaborate on the potential side effects on the nRF side. If there is a chance that this may cause a problem, this idea will be rejected.

Best regards,
Pascal

[Einar Thorsrud]

Hi Pascal,

The problem as I see it is that configuring TWIM->TXD.MAXCNT = 0 and starting transmission with TASKS_STARTTX is not a compliant method for TWI bus scanning. The fact that no LASTTX or STOPPED event is generated when the address is ACKed indicates that the peripheral is not completing a normal, valid transfer sequence. Because of this, using the absence of EVENTS_ERROR after a timeout as confirmation of ACK is not a robust solution. (And again, it is also a potential problem on the slave side.)

That is why I would recommend using a normal TWI/TWIM transfer for probing, as done in the twi_scanner example, and evaluating whether the addressed slave ACKs the transaction.

Br,

Einar