Turning a Sensor Off Does Not Turn It Off: Back-Powering Through Shared Bus Pull-Ups

Mostafa Dhouib·8 min read

Turning a Sensor Off Does Not Turn It Off: Back-Powering Through Shared Bus Pull-Ups

The short answer. You power-gate a sensor to save battery. Its supply rail goes to zero and the part stays awake anyway, because the pull-up resistors on the shared bus it sits on are tied to a rail that never switches off. Current flows from those pull-ups, through the sensor's data pins, through its internal protection diodes, and into the unpowered part. The sensor is back-powered through its own signal lines. No amount of choosing a lower-power sensor changes this, because it is not about the sensor. Take the pull-ups from the switched rail, and the bus goes down with the part.

Add a sensor to a battery product and the power budget is the first question. It is also the easiest question, and the answer is usually comfortable.

A humidity reading might cost something in the region of a few hundredths of a microamp-hour. A coin cell holds hundreds of milliamp-hours. The arithmetic is not close, and that is where most power analysis stops.

Then the device is built and the battery life is wrong, and the arithmetic is still correct, because the thing that broke was never in it.

The mechanism

A sensor on a shared bus has two signal lines, and both need pull-up resistors so the bus idles high. Those resistors have to connect to a supply. On most schematics they connect to the main always-on rail, because that rail is there, it is stable, and the bus is shared by several parts.

Now you power-gate the sensor. A transistor between the rail and the sensor's supply pin opens, and the sensor's supply pin goes to zero.

Its data pins do not. They are still connected to the bus, and the bus is still pulled high by resistors tied to the rail that never switched off. So the sensor now has zero volts on its supply pin and a positive voltage on its data pins.

Every one of those pins has a protection diode to the supply rail inside the part. Those diodes exist to clamp transients, and they conduct whenever a pin sits sufficiently above the supply. With the supply at zero and the pins held high, they conduct continuously. Current flows in through the data pins, through the diodes, and into the internal supply rail of a chip that is supposed to be off.

The sensor is now powered through its own signal lines. It may be partially powered, in an undefined state, drawing current the whole time. The datasheet's sleep current figure has no bearing on any of this, because the part is not asleep. It is being fed from a path nobody drew.

Why the usual instincts miss it

It is topological, not component-level. Nothing is wrong with the sensor, the transistor, the resistors or the firmware. Each is correct. The defect is in how they are connected, and a schematic review that checks parts against datasheets finds nothing.

The datasheet often says so, quietly. Many parts specify that their bus pull-ups should be powered from the same supply as the part. It is one line among hundreds, it reads as a formality, and it is the exact instruction that prevents this.

Your meter cannot see it. This is the practical reason it survives to production. The currents involved are small, and sleep-mode current in a well-designed device spans several orders of magnitude over a duty cycle. A bench multimeter reads an average over its integration window and is effectively blind across most of that range. A tool designed for the job resolves it. If your measurement says zero and the battery disagrees, trust the battery.

It is intermittent in a way that implicates software. The leak depends on what the bus is doing, which depends on firmware timing. So the symptom moves when the firmware changes, which sends everybody to look at the firmware, where the bug is not.

The fix

Take the pull-ups from the switched rail rather than the always-on one. When the sensor's supply goes down, the pull-ups go down with it, the bus is no longer held high, the diodes have nothing to conduct, and the part is genuinely off.

That has a consequence worth planning for: the bus is unusable while that rail is down, which matters when other parts share it. Options are to gate the whole bus segment together, to put the gated sensor on its own bus, or to use a bus switch that isolates the segment. Which one is right depends on what else is on the bus and how often each part is read, and it is a schematic decision rather than a firmware one.

The adjacent trap on the same part

While here, the second failure in this family is worth naming because it has the same shape and a different mechanism.

Taking a measurement from a sensor typically means issuing a command, waiting for conversion, and reading the result. The wait is tens of milliseconds. Implemented as a blocking wait, the processor sits there.

On parts without hardware-assisted bus transfers, a blocking wait starves whatever else needs the processor, and on a wireless device that includes the radio stack. The radio has timing obligations it cannot miss, so the link drops. The symptom is intermittent connectivity that correlates with sensor reads, and again it looks like a radio problem.

The fix is a non-blocking read: issue the command, schedule the collection, return control. Also topological in the sense that matters, in that no choice of sensor affects it.

How to actually check

Three things, and all are cheap.

Trace every pull-up to its rail, for every part you intend to gate. This is a schematic review with a specific question, and it takes minutes.

Measure with an instrument that can see sleep current, over a full duty cycle, not a multimeter reading an average.

Gate the part and confirm the bus actually falls. Probe the bus lines with the sensor gated off. If they are still high, the pull-ups are on the wrong rail and the part is being back-powered right now.

The honest limit

The arithmetic genuinely is fine. A sensor read at a few hundredths of a microamp-hour against a cell holding hundreds of milliamp-hours leaves enormous margin, and in a correctly connected design that margin is real.

That is the point rather than a caveat. Negligible impact is a property of the topology, not a property of the part, and the budget only describes what happens if the topology holds. The calculation tells you what the part costs. It cannot tell you whether the part is off.

FAQ

Why does my sensor still draw current when its power rail is switched off? Because the pull-up resistors on its shared bus are tied to a rail that never switches off. Current flows from those pull-ups into the sensor's data pins, through the internal protection diodes on those pins, and into the supply rail of a chip that is supposed to be unpowered. The part is back-powered through its own signal lines.

Will choosing a lower-power sensor fix a back-powering problem? No, because nothing about the problem is a property of the sensor. The leak is created by where the pull-up resistors connect, and it would happen with any part on that bus. The datasheet's sleep current is irrelevant because the part is not asleep.

Where should I connect I2C pull-up resistors on a power-gated sensor? To the same switched rail that supplies the sensor, so the bus falls when the part is gated off. Many datasheets state this explicitly. The consequence is that the bus is unusable while that rail is down, which has to be planned for if other parts share it.

Why can't my multimeter measure my device's sleep current? Because sleep current in a well-designed device spans several orders of magnitude across a duty cycle, and a bench multimeter averages over its integration window, leaving it effectively blind across most of that range. A purpose-built power analyser resolves it. If your meter says zero and the battery disagrees, the battery is right.

Why does my Bluetooth link drop when the device reads a sensor? Most likely a blocking wait during the measurement conversion. On parts without hardware-assisted bus transfers, the processor sits in that wait for tens of milliseconds and starves the radio stack, which has timing obligations it cannot miss. Issue the command, schedule the collection, and return control instead.

How do I check whether a part is genuinely powered down? Gate it and probe the bus lines. If they are still held high with the part's supply at zero, the pull-ups are on the wrong rail and the part is being back-powered. Also trace every pull-up to its rail during schematic review, which takes minutes and is the cheapest version of this check.