I am using 5 VCNL4040 boards, each through 2 Qwiic Bus endpoints, and all into a Qwiic Mux and Thing Plus S2. I am reading them fairly quickly, every 25ms scanning all of them at once. Im having an issue where sometimes these sensors will drop out, and never recover. Ive got a good robust sketch in place to do error detection, bus recovery, etc, but this is a stubborn issue that seems to be inherent to the sensor itself. Only a power cycle will let it unlatch and recover.
I could use a Qwiic power switch on each mux branch, but hoping there is a firmware solution. Any ideas, Sparkfun?
Just one mux. By mux branch i meant the ports. On each port, Qwiic Bus > cat5e > Qwiic Bus > VCNL4040.
The pullups were left as is, but I have a test bench setup identical but with Qwiic Bus and Mux pullups disabled. That works, but didnt test for long enough to replicate the issue. I do want to disable pullups on the other systems, but they are in different locations. Ill do it if you think its the problem.
In general you should disable all but one set per bus…so for any number of sensors on a given mux, usually I advise leaving the mux’s i2c pull-up intact and disabling all of the ones on-board the sensors (easiest way to keep track of what is where)
Ok. Lets just assume pullups are addressed, but the issue continues to pop up. What is it about the VCNL4040 that puts it in to an unrecoverable state? Is it not tolerant of voltage variation? I2C timing drift? I2C edge variance? Is there a way to recover it, short of disconnecting it with something like a Qwiic Power Switch?
It could be a lot of things…but there isn’t a known issue with those (esp32 can have issues with clock stretch, timing conflicts, possible brown-out if the sensors are active simultaneously).
Isolate some variables by testing with one sensor by itself and see you encounter the same error