VL53L8CX SPI datasheet ambiguity: MISO push-pull output vs 47k pull-down in Figure 6

[AlexkseiR]

I am trying to understand one point in the official VL53L8CX datasheet.

In the pin description table, pin C5 (MISO) is described for SPI as:

“SPI: Main input secondary output. Push-pull output, driven to IOVDD level.”

But in Figure 6 (“Typical application schematic for SPI”), the MISO line seems to have a 47 kΩ pull-down resistor to GND.

I attached two screenshots:
1. the table entry for C5 / MISO
2. the SPI typical schematic with the suspected 47 kΩ pull-down highlighted

My question is: how should this be interpretedcorrectly?

Does ST mean that MISO is a push-pull output, but an external weak pull-down is still recommended as a default line state? Or is this schematic being misread, and that 47 kΩ resistor actually belongs to another signal?

I would appreciate clarification from anyone who has used VL53L8CX in SPI mode or has already resolved this ambiguity.

[Bin]

Hi:

1. The datasheet description of C5/MISO refers to the pin output structure
The sentence: SPI: Main input secondary output. Push-pull output, driven to IOVDD level. means that:

when C5 is used as SPI MISO:
this pin is a digital output,
its output stage is push-pull,
and its high-level output is driven to the IOVDD voltage domain.
In other words, the internal driving capability of the chip will actively pull this pin up/down

2. The 47 kΩ resistor in Figure 6 refers to the board-level default state / startup behavior
The 47 kΩ pull-down to GND shown in the schematic does not mean that MISO depends on it for normal operation, and it does not imply that MISO is open-drain.

It is better understood as a weak pull-down, used to give the line a defined default state in certain conditions.

Typical reasons for such a resistor are:
to prevent the line from floating during power-up or reset
to provide a defined low level when the sensor is unpowered or its I/O is in high-impedance
to reduce noise susceptibility
to avoid undefined logic states during startup or multifunction-pin transitions

3. Why can a push-pull output still have an external pull-down resistor?
Because 47 kΩ is a large resistance, so it acts only as a weak bias.

When the VL53L8CX actively drives MISO high:

the output high level is approximately IOVDD
the pull-down resistor only sinks a very small current
For example, if IOVDD=3.3V:

I≈70 μA

This current is very small, so it has essentially no practical impact on a push-pull output.

So:

when MISO is low: the sensor actively pulls it low, and the resistor is simply consistent with that state
when MISO is high: the sensor actively pulls it high and only needs to overcome about 70 μA of pull-down current.
Therefore, both can coexist without issue.

4. What is the key purpose of this 47 kΩ pull-down?
The important point is:

the resistor only matters when no one is actively driving the pin.

That includes cases such as:

the sensor is not powered
the sensor is in reset
SPI is not yet active
the pin is temporarily in high-impedance state
In those situations, the MCU does not see a floating MISO pin. Instead, the 47 kΩ resistor forces it to a defined low level.

Once the VL53L8CX is operating normally and driving MISO, the pin state is determined by the internal push-pull driver, not by the resistor.

Hope my explanation will help for you.

[AlexkseiR]

Hi everyone,

I would like to continue this discussion because I am trying to understand whether my design approach is fundamentally sound, or whether I am relying too much on firmware sequencing in a way that is considered unsafe for a real product.

I am not a hardware engineer. I am doing this project mostly on my own, and I am actively using AI as a helper to understand the schematics, datasheets, and reference designs as carefully as I can. I have tried to follow the available ST and vendor references as closely as possible, but I would really appreciate a human sanity check from people with more practical hardware experience.

My current board uses a VL53L8CX with an ESP32-S3, and I want to support both I2C and SPI on the same hardware. My current implementation is roughly as follows:

- The sensor 3.3 V rail is power-gated by an AP22913 load switch controlled by the ESP32.
- The 1.8 V rail for the sensor core / IOVDD is generated by a TPS79318.
- I use PI4ULS3V204 level shifters between the ESP32 side and the sensor side.
- The interface-selection / control lines on the sensor side are biased with resistors:
- `SPI_I2C_N` has `47 kΩ` to GND
- `NCS` has `47 kΩ` to GND
- `MISO` has `47 kΩ` to GND
- `SDA/MOSI` and `SCL/MCLK` have `2.2 kΩ` pull-ups to `IOVDD (1.8 V)`
- `SYNC`, `INT`, and `LPN` have `47 kΩ` pull-ups to `IOVDD (1.8 V)`

One important detail I want to state explicitly: on the ESP32 side, `GPIO17` and `GPIO18` also have their own `5.1 kΩ` pull-ups to `3.3 V`. So the bus is not only biased on the sensor side; there are also pull-ups on the MCU side of the level shifter, and I marked that intentionally on the schematic.

My intended firmware contract is the following:

1. Keep the sensor power disabled.
2. Pre-set the mode pins from the ESP32:
- `SPI_I2C_N = 0` for I2C, `1` for SPI
- `NCS = 0` for I2C, `1` for SPI idle
- `LPN = 1`
3. Only after those levels are already defined, enable `SENSOR_3V3`.
4. Wait for power to settle.
5. Initialize the sensor in the selected interface mode.
6. If I ever need to switch between I2C and SPI, I do not plan to hot-switch the interface. I plan to treat that as a full sensor power-cycle event.

So in my case, interface selection is not meant to happen “live” while the sensor remains powered. It is meant to happen only while the sensor power is off, and only then the sensor is powered back up in the required mode.

This is the main reason why I am questioning how strictly I should interpret the passive resistor recommendations in the VL53L8CX documentation.

My current understanding is:

- The `47 kΩ` on `SPI_I2C_N` is only a default state.
- The `47 kΩ` on `NCS` is also only a default state.
- Once the ESP32 actively drives those signals before sensor power-up, those resistors should not prevent the line from reaching a valid logic level.
- `MISO` is not used in I2C mode, so I assumed that a weak `47 kΩ` pull-down there would be harmless in practice.

However, this is exactly where I am unsure, because the ST documents seem a bit ambiguous depending on which table or figure is being read.

For example:
- In the VL53L8CX datasheet, Table 3 says that in I2C mode `MISO` is “Do not connect”.
- At the same time, some reference-style drawings show weak resistors around these mode-related lines.
- In SPI mode, `MISO` is of course an active output, so the practical question is whether a weak `47 kΩ` pull-down is acceptable there, or whether ST would consider that a bad idea despite being weak enough not to create a meaningful DC load.

What I am trying to understand from experienced engineers is this:

Does this architecture look fundamentally workable if the firmware strictly enforces the power-up sequence?

In other words:
- define the interface mode first,
- keep the sensor unpowered while doing so,
- then apply sensor power,
- then initialize the device,
- and treat any I2C/SPI mode change as a full power-cycle + reinitialization event.

Or is this still considered too fragile / too far from ST intent, even if the firmware contract is respected?

I am not looking for theoretical perfection here. I am trying to understand whether this design is realistically workable as intended, or whether I should redesign it now before ordering boards.

If you think this can work, I would also appreciate practical advice on what you would change to make it more robust.
If you think it is a bad idea, I would really appreciate a direct explanation of which exact part is unsafe:
- the `MISO` biasing,
- the `NCS` default pull-down,
- the interaction with the level shifters,
- the dual-side pull-ups,
- or the whole “mode is chosen by firmware before power-up” concept itself.

For reference, the main documents I have been using are:
- VL53L8CX datasheet, DS14161 Rev 12:
https://www.st.com/resource/en/datasheet/vl53l8cx.pdf
- UM3109 Rev 12:
https://www.st.com/resource/en/user_manual/um3109-a-guide-to-using-the-vl53l8cx-timeofflight-multizone-ranging-sensor-with-enhanced-ranging-performance-stmicroelectronics.pdf
- PI4ULS3V204 datasheet:
https://www.diodes.com/datasheet/download/PI4ULS3V204.pdf
- AP22913 datasheet:
https://www.diodes.com/datasheet/download/AP22913.pdf

I am attaching the relevant schematic snapshot as well.

Thanks in advance — I would really value a practical, human review of whether this will work the way I think it will.

[TDK]

> or the whole “mode is chosen by firmware before power-up” concept itself.

I would suggest developing for SPI or I2C, not both. It will simplify the project so you can focus on other things. If you need the speed, use SPI. Otherwise use I2C. This should not be taking up so much time.

[AlexkseiR]

Thank you, that is probably the most practical and sensible advice.

I do understand the logic of “don’t overcomplicate it, pick either SPI or I2C and move on.” If I were looking at this purely as an engineering product that just needs to be finished efficiently, that would probably be the right decision.

But there is another side to this for me. I am not an engineer. Just two months ago, I could barely explain the difference between a resistor and a capacitor, and any schematic was honestly overwhelming to me simply because I did not know how to read one. Right now this is more of a hobby for me, but also a very intense learning process.

In that sense, AI has dramatically lowered the barrier to entry. It allows someone without a formal background to even approach problems like this. In practice, what it really takes is a good prompt, a lot of patience, and constant verification. And the more you cross-check things, ask questions, catch inconsistencies, and correct mistakes, the more you start to understand areas you had never dealt with before.

But there is also a downside: at some point, AI starts sounding very convincing. After it has already helped find and fix a large number of mistakes, it becomes very tempting to just believe that “now everything must be fine.” That is exactly why it is so important to me to hear opinions not only from AI, but from people for whom this is a profession rather than a two-month hobby.

So my question at this point is not really whether I should simplify the design in the next revision. What I am trying to understand is whether, in its current form, this schematic is fundamentally viable or not. Will it actually work the way I intend if I strictly enforce the sequence of power-off -> preconfigure GPIO -> power-on -> init? Or is there already a hardware flaw in the concept itself, regardless of firmware?

So, to put it briefly: I am not arguing against the idea that choosing only one interface would be simpler and more reasonable. What I am trying to understand is whether my current approach is just unnecessarily complicated but still workable, or whether it has already crossed the line into being a bad engineering decision.