TCA Multiplexer can permanently lock the I2C Bus

[dbgen1]

If the following scenario occurs, it is possible that the I2C bus can become permanently locked, causing the code to hang indefinitely without actually crashing or rebooting:

How to reproduce

• The TCA device must be malfunctioning or unreachable at its I2C address. This can be achieved in testing by trying to run the code on just the flight controller with no battery board attached.
• The TCA try_lock() must be called. This happens naturally when running the code normally. What happens is the following:

Sequence of events

1. After boot, the device is initialized in pysquared.py. Despite the device not physically existing at the specified address, the initialization of the TCA9548A succeeds.
2. In main, once operations reaches the point of trying to get data from the faces, the TCA9548A_Channel#try_lock is called (which is correct).
3. Since the TCA class was initialized, this locks the I2C bus. It then attempts to write to the physical TCA device at its I2C address, but since it doesn't exist, the code errors out.
4. The I2C bus is never unlocked. The next time the try-lock is called, it enters an infinite loop.

Potential Solution

This may also be an issue for other hardware devices. Ideally, the device drivers should not get to the point of being successfully initialized if the device itself is unreachable at its address. One possible way of fixing this potential issue is by checking the I2C addresses where a device is meant to be before attempting to initialize the device. Another possibility is modifying the device driver to check this itself before doing anything else, and especially before entering any loops.

[Mikefly123]

Very interesting! #25 describes how I discovered the last part of what you're talking about where the try-lock() can enter an infinite loop!

This is how I fixed the infinite loop thing:

[dbgen1]

For now, we decided to fork the TCA library to a repo in the proveskit org and add a check for the i2c address in the initialization of the TCA. This issue is also the cause of the board going to sleep forever when tested without a battery board attached (caused by the I2C lock). Preventing the TCA initialization seems to fix the problems, so I am marking this as understood for now, but leaving it open as more testing is required with the forked library.

[Mikefly123]

I'm linking our forked TCA library here: https://github.com/proveskit/Adafruit_CircuitPython_TCA9548A

[Mikefly123]

@dbgen1 do you think we could maybe make a PR to merge both our modified TCA library and your updates to the RTC library with main so we can shake down if the changes to the lib are sufficient to quash this issue?