2025-12-15 4:12 AM
I have an application that uses 10 VL53L0X sensors on an I2C bus. I seem to have ended up damaging multiple STM32 dev boards trying to get this configuration to work reliably. Any help to understand what I am doing wrong would be appreciated.
So, there are 10 VL53L0X sensors on a single I2C bus connected to the I2C port on a Nucleo dev board. There is a mechanism to enable each independently to set the I2C address, after which they all operate in continuous sampling mode and the MCU polls for results periodically. This works fine, sort of, and the data comes in OK. At some point everything stops and that's the end of it. I have found that the I2C port on the dev board seems to have been damaged and no longer works at all (probing with multi-channel scope). There was nothing else connected to the dev board, just the I2C lines.
The VL53L0X sensors have their own 3V power supply which is manually switched and is independent from the power to the dev board. In normal polled operation I noted that the sensor power was taking about 200mA; which seems quite a lot to me but maybe that's normal. My suspicion is that I may at some point have had the dev board powered but without power to the sensors. Could that somehow have overloaded the I2C bus lines and damaged the dev board?
Before I risk trying another of my dwindling stock of dev boards I want to make sure I am not going to break anything else. Should I be using some sort of isolation on the bus between the sensors and the sensors and the dev board? Am I missing something obvious? I wasn't expecting that anything on an I2C bus could potentially damage the master I2C port.
Open to ideas and suggestions.
Solved! Go to Solution.
2025-12-30 2:17 PM
Mike -
the I2C is a notoriously unreliable bus. It works, until it doesn't. And any glitch on the line will 'hang the bus'. When idle both SDA and CLK lines should be high. if they are not, then you have an issue related to a glitch on one of the I2C lines. Proper pull-ups, resisters and noise isolation is imperative. Keeping those lines as short as possible is another great idea. Read up on how to size your pullups. Lots of google information.
the sensors - when running - will max out at 20mA. Anything above that is a problem.
But if you only pole occasionally you can tell the sensor to pause between ranges. Use the intermeasurement period and the timing budget to set how often the sensor ranges.
- john
2025-12-15 4:56 AM
Powering the dev board and the sensors independently should cause no issues.
But pulling 200 mA does indicate a hardware issue. Perhaps something else happened.
Perhaps show a picture of your setup. Place board on a non-conductive surface. Be wary of shorting random pins together.
2025-12-17 12:08 AM
Thanks for the suggestions. I have ordered a replacement dev board as well as I2C isolators. I will make sure the board is fully isolated before trying again. Will also double check wiring etc.
2025-12-30 2:17 PM
Mike -
the I2C is a notoriously unreliable bus. It works, until it doesn't. And any glitch on the line will 'hang the bus'. When idle both SDA and CLK lines should be high. if they are not, then you have an issue related to a glitch on one of the I2C lines. Proper pull-ups, resisters and noise isolation is imperative. Keeping those lines as short as possible is another great idea. Read up on how to size your pullups. Lots of google information.
the sensors - when running - will max out at 20mA. Anything above that is a problem.
But if you only pole occasionally you can tell the sensor to pause between ranges. Use the intermeasurement period and the timing budget to set how often the sensor ranges.
- john
2025-12-30 3:10 PM
Thanks for the suggestions. I have added I2C isolators between the dev board and the sensor array. So far, that has prevented any more blown boards. Noise was indeed a big problem. There was a large inductive load being switched with relays and that was causing havoc with the I2C bus and with the 'enable/reset' lines to each sensor. Having set the I2C address this was later being reset by the spurious spikes on the enable lines so all the communication fell apart. A different switching mechanism on the load helped with that problem. At the moment the 10 sensor array is working quite well at 400KHz bus speed and with some less than wonderful long wire runs so I am probably just getting lucky. Some refinement is still needed and I will note the comments about cable lengths, pull-ups and sensor modes for any improvements.
Mike.