BLOG

PMBus Address Conflicts: Why Does a Controller Detect Only One of Several Power Supplies?

Quick answer: A controller can detect only one of several power supplies when modules share an address, the host uses the wrong address convention, or the inventory map confuses management targets. A missing response can also have other causes, so an address conflict is a hypothesis to verify.

The PA350R-212A-R rack supply source lists FRU/PSU address pairs and address-select states. That makes the mapping concrete, but it also creates two common traps: treating a FRU target as the power-management target and copying a displayed address into a host API that expects a different notation.

Begin with the approved platform inventory and read-only evidence. This article does not prescribe arbitrary bus scans, configuration writes or live backplane changes. The objective is to associate each physical bay with the correct logical target before using its telemetry for diagnosis.

Build a physical-bay-to-address map before interpreting replies

A bus reply identifies a responding logical target; by itself it does not establish which physical module produced the response. If several installed PSUs share a selection state, a controller may not distinguish them reliably. Conversely, a display showing one device can reflect an inventory or software-mapping issue even when the electrical addresses are distinct. Keep physical inventory and observed replies as separate evidence.

The PA350R technical data shows A0, A1 and optional A2 addressing information, including six example selection rows. The source also lists redundant operation up to six units. Those statements do not automatically prove that every installed backplane exposes the optional selection or supports the same six-module map. Confirm the actual hardware and revision.

Create a compact record for each bay: module identity, configured option, documented select state, expected target and observed result. Use supported inventory and diagnostics rather than changing addresses to see what appears. A map that includes empty bays and repeated expected addresses can reveal a configuration conflict before any bus transaction is changed.

Why This Matters

• A logical response must be associated with a physical module before its data is actionable.
• Optional address selection and the installed backplane determine the usable address map.

What OEMs Should Do Now

• Compare the approved bay map with installed module identities and documented select states.
• Mark repeated expected addresses and unknown options for confirmation before changing configuration.

FEATURED PRODUCTS

MORE INFO >>>

Open Frame / Internal PSU

PA350R-212A-R

• Output Power - 350W
• Output Volt - 12V
• Features - This rack-mount power supply accepts AC line input voltage from 100Vac to 240Vac or DC voltage from 180Vdc to 300Vdc,provides 350 watts of 12Vdc main and 5Vdc standby power. This high power density power supply features a fully digital design, supports the PMBus communication protocol, and is equipped with short circuit, overcurrent, over-voltage, and over-temperature protection.

<

>

Keep the FRU target distinct from the PSU target

The PA350R address table presents a FRU/PSU pair for each selection row. Its first row lists 0xA0/0xB0, followed by pairs such as 0xA2/0xB2. Do not treat the first target as automatically interchangeable with the second. A reply from a module-information target does not prove that the expected power-management command will work at that same address.

Retain the table exactly as documented while confirming the convention used by the platform. The address values below are source notation, not ready-to-copy arguments for every host library. The optional A2 line affects the higher rows, so verify its implementation before assuming that six distinct selections are available. Keep the FRU and PSU roles explicit in controller configuration and diagnostic logs.

If an inventory read succeeds but power telemetry does not, compare the selected target and supported command before concluding that the whole module is unavailable. Also check transaction type and revision-specific command support. A responding target can still return an error for a command it does not support; that is a different observation from no response.

Why This Matters

• FRU inventory and PSU management can use different logical targets on the same module.
• A successful response at one target does not validate another target or command.

What OEMs Should Do Now

• Label each expected address by role and verify the role used by the host.
• Confirm optional A2 support before relying on source rows that require it.

Resolve seven-bit versus eight-bit address notation explicitly

Host APIs and documentation do not always display an address in the same way. A seven-bit slave address is distinct from a byte representation that includes a read/write position. Copying a hexadecimal number without understanding the convention can make a correct hardware selection appear absent. The PA350R table does not sufficiently define the display convention for a universal host-code example here.

Confirm how the controller API expects the target and how the supplier table expresses it. Do not pass 0xB0 into a seven-bit field simply because it appears in the source, and do not silently shift values without documenting the agreed interpretation. A conversion should follow verified conventions on both sides, not an assumption based on the familiar shape of the table.

Preserve three separate values in the engineering evidence when needed: the source notation, the normalized logical address and the exact host configuration value. This avoids applying a conversion twice between a configuration file, driver and bus library. Keep this detail in the technical mapping, while the operator-facing inventory can remain a simple bay-to-module view.

Why This Matters

• A notation mismatch can mimic a missing device even when the physical address selection is correct.
• Applying a conversion twice can reproduce the same failure after a well-intended correction.

What OEMs Should Do Now

• Confirm supplier and controller conventions before converting or writing any address value.
• Trace the value through configuration and driver layers to ensure one agreed representation.

Distinguish an address conflict from communication and identity problems

A missing response can reflect an address conflict, wrong target, unsupported transaction, communication path issue or an unavailable module. Diagnose these as separate possibilities. Start with the supported system log and known expected configuration; preserve error type, target and timestamp. Do not use a single “not detected” label to collapse all failure modes.

The PA350R command table lists PMBus revision 1.2 at 100kHz and identifies supported read transactions. Match the host behavior to the current approved implementation. The public table’s manufacturer-model example shows a different model string from the PA350R document title. Treat that as a documentation ambiguity to confirm, not as a reliable exact-match identity assertion or proof that a returned unit is counterfeit.

The PMBus management guide gives broader context, and the redundant load-sharing guide explains why multiple modules may operate on one system. Neither guarantees that a bus inventory reflects every individual module correctly. Cross-check module identity and electrical state through the supported platform information before assigning a hardware fault.

Why This Matters

• A missing response is a symptom with several plausible causes.
• An inconsistent identity example should not become a hard-coded rejection rule.

What OEMs Should Do Now

• Retain the exact communication error and distinguish no response from unsupported-command results.
• Confirm expected identity strings and command behavior for the delivered revision.

How Phihong supports an address-map review

For PA350R-212A-R, provide the bay inventory, module revisions, address-select options, source notation, controller API convention and observed read-only results. Include which requests target FRU data and which target PSU management. Ask Phihong to confirm the supported addressing arrangement and expected identity response for the project configuration.

Use the approved platform procedure for any later configuration change. Do not infer drive levels, pull-ups or live-service permissions from the address table. Optional features, bus implementation and the physical interface need their own confirmation. A public six-unit redundancy statement does not remove the need to qualify the installed controller, backplane and selected options.

Retain the confirmed map with the rack power-system architecture record and controller configuration. A useful acceptance check associates each expected bay with one verified management identity and records missing or conflicting entries clearly. It should preserve evidence and avoid arbitrary writes, broad scans or changes to operating power modules as a first diagnostic step.

Why This Matters

• A shared confirmed map prevents software and hardware teams from using incompatible address assumptions.
• Revision-specific identity confirmation avoids false replacement decisions.

What OEMs Should Do Now

• Request written confirmation of address notation, target roles and optional selection support.
• Validate the agreed map through supported read-only inventory before enabling automated fault actions.

Useful Links: PA350R-212A-R product details · PA350R-212A-R technical datasheet

Related Links: Rack PSU diagnostic workflow · AC_OK versus PW_OK · Main and standby fault recovery · PMBus management fundamentals · Multiple-PSU load sharing · Intelligent rack power guide

Frequently Asked Questions

Does only one detected PSU prove an address conflict?

No. It is one hypothesis. Wrong target selection, notation mismatch, unsupported transactions, communication faults or inventory mapping can create similar symptoms.

Can I copy 0xB0 directly into a seven-bit address field?

Do not assume that is valid. Confirm the convention used by the source and the host API, then document the correct representation and any conversion.

Are FRU and PSU addresses interchangeable?

They identify different documented target roles. Verify which target supports the information or management command being requested rather than relying on any response from the module.

Does a six-unit redundancy listing guarantee six addresses on my backplane?

No. Confirm the installed addressing options, including optional A2 support, and the actual controller/backplane implementation for your configuration.

Should the published model-string example be an exact identity check?

The public command example differs from the document title. Confirm the expected delivered-revision response with Phihong before hard-coding an identity acceptance rule.