Zephyr 1-Wire Expansion: A Supplied ROM Does Not Always Select One Sensor

A product originally has one 1-Wire temperature probe. A later harness adds a second probe, and the application already knows both ROM identities. It is tempting to assume that passing the intended ROM into a transaction guarantees addressed communication. In Zephyr v4.2.0’s network layer, selection also depends on configured topology and a build option.

The concrete risk is continuing to issue Skip ROM after the physical bus has expanded. This article follows the selection implementation and the DS18B20 driver’s initialization path. It does not claim that every second-probe connection causes corrupted readings, or that discovery automatically repairs the product’s configured device model.

Distinguish configured count from discovered devices

The pinned 1-Wire interface implements w1_get_slave_count() by returning slave_count from the master’s configuration structure. That call does not scan the wire. A nearby devicetree macro computes an expected count from dependency information; it is not a runtime enumeration result. The pinned GPIO master initializes this stored field using W1_INST_SLAVE_COUNT(inst), making that build-time origin concrete for this backend.

Runtime search is a separate operation. In the pinned network implementation, search walks ROM identities, invokes the supplied callback for discoveries, and returns a count or an error. That code does not update the master’s stored configuration count.

Keep these observations in separate diagnostic fields. “Configured count: one” and “search found: two” describe a mismatch worth investigating, not contradictory readings from one sensor-count API. Handle search failure explicitly; a failed enumeration is not proof of an empty or single-device bus.

Trace the selection branch literally

The network layer’s internal reset_select() uses Match ROM if CONFIG_W1_NET_FORCE_MULTIDROP_ADDRESSING is enabled or the configured count exceeds one. Otherwise it uses Skip ROM. The supplied ROM’s nonzero value is not an additional condition in that decision.

Both the public reset/select helper and the combined write/read path use that selection logic. Consequently, merely filling in a specific sensor identity does not override a build that still follows the single-drop shortcut. Review the common helper called by the transaction rather than assuming the public argument alone determines the wire command.

The pinned 1-Wire Kconfig explicitly provides forced multidrop addressing for situations involving multiple devices not represented in DTS. It prevents the network layer from taking the Skip ROM shortcut. That option does not discover identities, assign product roles, or establish that a particular probe is connected.

Why a harness change can alter the meaning of a read

Consider a proposed configuration with one expected slave, forced multidrop disabled, and an application transaction carrying probe A’s ROM. If the physical harness contains A and B, the examined helper still selects Skip ROM from the configured count. Supplying A’s identity has not made this transaction exclusive to A.

The resulting electrical and protocol behavior depends on the command and devices. Some commands may intentionally support a broadcast use, while a read expecting one addressed response needs a different contract. Do not infer a particular numeric failure, a guaranteed CRC error, or a trustworthy sensor identity merely from whether a transaction returned success.

The acceptance question is narrower and testable: did the emitted ROM-selection operation match the intended recipient? Capture that fact before explaining a plausible temperature reading. A familiar room-temperature value cannot establish which physical probe supplied it.

DS18B20 readiness does not finish probe binding

The pinned DS18B20 driver initializes its stored ROM to zero and defers configuration. Its initialization checks bus readiness; actual sensor configuration occurs on the first sample-fetch path.

During deferred configuration, a configured slave count of exactly one allows the driver to try Read ROM when no ROM was assigned. For other counts, an unset ROM is rejected. The driver also exposes SENSOR_ATTR_W1_ROM to assign the sensor identity and marks its deferred configuration as needing to run again afterward.

This means that a ready device object is not evidence that the application’s multidrop probe identities have been bound successfully. Configure the intended identity before accepting measurement service, and treat the first fetch as another operation that can fail. Inspect family and communication failures separately from the master driver’s readiness.

Do not treat a forced-addressing setting as a replacement for this binding. Match ROM needs the correct identity. A valid but incorrectly assigned ROM can produce readings from the wrong installed location without violating the basic addressing protocol.

Make probe identity a product interface

Maintain a mapping from physical role to ROM: inlet, outlet, enclosure, or another actual measurement location. Define how that mapping is commissioned and how a replacement probe is accepted. Enumeration order should not become a hidden substitute for physical role.

A service procedure can compare expected identities with observed search results and require an explicit replacement decision when an identity changes. Preserve absent, unexpected, and unavailable-search outcomes separately. Do not silently relabel an unexpected device as the missing probe just because the total number of discovered devices matches.

For each board and harness variant, retain the master configuration, effective forced-addressing option, expected device descriptions, and role-to-ROM map. Review them together when adding a sensor connector or optional probe. A hardware expansion can require a firmware addressing-policy change even when the temperature-driver API stays identical.

Verify selection without relying on temperature plausibility

Begin with a fake or instrumented master that records outgoing commands. Test configured counts of one and greater than one, each with forced multidrop disabled and enabled. Supply a nonzero ROM in every case and assert the selection branch, including the fact that it does not independently force Match ROM.

Then verify that the addressed path transmits the intended ROM bytes and that transport errors remain visible. Separately test the DS18B20 first-fetch path with an unset and an explicitly assigned identity. These software fixtures establish dispatch behavior; they do not establish electrical bus margins.

On an isolated hardware setup, use distinct qualified probe identities and a trace of the ROM-selection traffic. Confirm the product’s physical-role mapping independently of temperature values. Keep wiring, pull-up capability, cable limits, and sensor power mode within their own documented requirements; the examined DS18B20 driver does not support parasite power.

No bus scan, probe transaction, executable fixture, or hardware measurement was performed here. The source-derived rule is that configured topology participates in addressing. Discovery, identity assignment, and command selection must agree before one reported temperature can be attributed to one installed probe.

Trend context

The archived Google Trends “embedded os” export covers worldwide web search, all categories, July 19–October 19, 2026. RISING related queries include “zephyr os” at +300% and “zephyr” at +40%. Those parent-topic figures motivate Zephyr coverage; they do not measure demand for 1-Wire addressing or this article’s title.