← Back to: eFuse / Hot-Swap / OR-ing Protection
What This Page Solves
Traditional protection devices like fuses or transient suppressors can interrupt dangerous current surges—but they lack one crucial trait: context. They react blindly, without telling you what went wrong, how often it happened, or whether it’s safe to power back up. In a modern system, this is no longer sufficient.
An eFuse combines hardwired protection mechanisms with digital diagnostics and service hooks. It doesn’t just shut off power—it provides actionable fault classification, counts how many times it happened, stores programmable limits, accepts remote disable commands, and flags itself for service if needed. It is no longer just a protection IC; it is a power-path decision node.
This diagnostic capability is crucial in systems that require:
- Remote or cloud-based fault analysis
- Smart power sequencing and recoverability
- Minimal downtime through predictive replacement
- Field-replaceable module tracking (FRU-friendly design)
In this context, “Diagnostics & Service” is not a bonus feature—it is the foundation for how modern power-path systems maintain safety, continuity, and visibility.
Fault Classes & Counters
Not all power-path faults are equal. A short-circuit event poses a different level of risk than a momentary inrush surge or a user-induced hot-plug spike. Modern eFuses support fault classification logic to distinguish these cases and apply different response strategies: instant shutoff, retry mode, or telemetry-only logging.
Typical categories include:
- Class A: Permanent damage threats — Short circuit, reverse polarity, thermal runaway. → Immediate latch-off.
- Class B: Recoverable disturbances — Inrush, brief overvoltage, temperature spikes. → Retry or hiccup mode.
- Class C: User-generated events — Illegal hot-plug, connector bounce. → Log only or delayed reporting.
In parallel, event counters are used to track how often faults occur. These may be simple sticky bits (latched until cleared) or rolling counters used to implement retry windows—e.g., 3 trips before entering permanent fault mode. The PG/FAULT pin can be linked to these thresholds, allowing the system to differentiate between transient blips and persistent degradation.
These classification and counting mechanisms are foundational for smart diagnostics, remote telemetry, and proactive servicing of Field Replaceable Units (FRUs).
Programmable Thresholds
eFuses offer configurable protection thresholds for current, voltage, temperature, and timing. These parameters define how the eFuse reacts under fault or stress conditions—and the more precisely they’re tuned, the better the system can balance protection and availability.
The key programmable thresholds include:
- ILIM: Defines current limit during overload. Impacts power consumption and Safe Operating Area (SOA).
- OVP / UVLO: Voltage protection windows. Helps determine power-on/off sensitivity and battery safety margins.
- TSD: Thermal shutdown temperature. Tied to layout heat dissipation and junction rise prediction.
- Delay / Blanking: Time filters to suppress false trips from inrush or transient noise.
Configuration can be done through I²C or PMBus interfaces at runtime or OTP fuses at production time. Dynamic interfaces enable adjustment during temperature changes, EMI stress, or power mode shifts.
Thermal Shutdown (TSD) is not just a safety fallback—it must be coordinated with board layout and heat spreading. Junction temperature can rise rapidly under high-current or compact layout, so the selected TSD point should consider worst-case ambient + layout RθJA. In precision systems, designers may combine TSD with external NTC-based soft derating logic before thermal cutoff is even triggered.
For example, an inrush current lasting 20µs should not trigger a fault if the blanking time is configured to 50µs. This allows legitimate startup behavior while still protecting against sustained overloads or short circuits.
Remote Disable & Power Limit
eFuses support system-level control via remote disable and power-limiting mechanisms. These features allow intelligent shutdown or current throttling in coordination with MCU, gateway, or cloud policies. Instead of simply reacting to faults, the system can proactively reduce stress or cut power gracefully.
Remote disable can be triggered through:
- EN pin: Local hardware signal; used for board-level sequencing and quick cut-off.
- I²C / PMBus: Register-based command from MCU or remote controller; allows conditional shutdowns, field servicing, or power sequencing from firmware.
In more advanced systems, cloud-based control (via BMS or gateway) can send down a disable instruction—enabling diagnostics, servicing, or safety modes without manual intervention.
Compared to physical EN assertion, digital disable allows context-aware logic: shutdowns triggered only under verified risk, low SoC, thermal excursion, or time-based derating.
Separately, Power Limit Mode enables the eFuse to throttle output current—typically by adjusting ILIM down to 70–80% of its normal rating. This is useful in:
- Old or degraded cables where voltage drop needs compensation
- Battery aging scenarios where load needs soft derating
- Thermal mitigation without causing service outage
The PG/FAULT pin can reflect whether a disable or derating condition is active. Systems can log this or notify user for preemptive maintenance.
FRU-Friendly Design
In field-replaceable designs, eFuses must support diagnostics that persist across module swaps. A well-designed eFuse system doesn’t just shut down safely—it also remembers, identifies, and resets in a serviceable way. This makes them “FRU-friendly” for industrial, automotive, and edge systems with minimal downtime.
Persistent fault tracking is essential. An eFuse module should store its last known fault state—such as trip class, event count, or timestamp—into non-volatile memory (EEPROM or internal flash). On reinsertion or power-up, this data allows the system to decide whether to enable the path or enter a locked state.
Each FRU should also be uniquely identifiable. Common approaches include:
- Device ID for silicon-level tracking
- Part Serial for batch traceability
- FRU handshake logic to perform soft self-test before power-on
If a FRU is marked “locked” due to fault limits or persistent issues, the system can either deny reactivation or enter service override mode. This requires unlock mechanisms such as:
- Sending
soft_unlockcommands via I²C - Writing to a fault-reset register under technician control
After unlock, the FRU must reinitialize counters and clear stored fault metadata to avoid false diagnostics. This ensures clean operation for the next lifecycle.
IC Selection Guide Across 7 Brands
1) Decide diagnostic level first
Telemetry-Ready > Classed Fault > Basic PG — pick the minimum that meets service/remote needs.
2) Match the control interface
Board-level sequencing uses EN/PG; cloud/MCU policies need I²C/PMBus (remote disable, ILIM adjust).
3) Check compliance and packaging
If automotive, verify AEC-Q availability; pick packages and thermal limits aligned to your stack-up.
| Function | TI | ST | NXP | Renesas | onsemi | Microchip | Melexis |
|---|---|---|---|---|---|---|---|
| Basic Fault PG PG/FAULT indicator |
TPS2595 (PG) | STLQ020 (PG) | PCA9430 (PG) | ISL6144 (PG) | FPF2190 (PG) | MIC2090 (PG) | MLX91220 (PG) |
| Classed Fault classified response/counters |
TPS25947 (classed) | L7987L (classed) | GD3162 (classed) | ISL6146 (classed) | NCP3902 (classed) | MIC28517 (classed) | MLX91208 (classed) |
| Telemetry (PMBus) I²C/PMBus readable |
TPS25985 (I²C/PMBus) | L99VR01 (I²C) | PCF2131 (I²C) | ISL71043 (I²C) | FPF300x (I²C) | UCS2112 (I²C) | MLX91231 (I²C) |
Notes: Examples reflect representative devices for diagnostic capability tiers. Verify package, limits, and AEC-Q options per brand datasheet before committing a design.
FAQ
How should I choose ILIM, OVP/UVLO, and blanking to avoid nuisance trips?
Start with ILIM at 1.2–1.5× the steady load plus measured inrush. Set UVLO above the supply ripple valley and OVP below the absolute maximum of downstream parts. Measure inrush duration and pick blanking longer than that by a safety factor. Validate under temperature corners and worst-case cable drop before freezing values.
When is power-limit better than an immediate cut-off?
Use power-limit when continuity matters but stress must be reduced. Typical cases include aging batteries, long cables with voltage droop, or thermal excursions where graceful degradation avoids brownouts. Set ILIM to 70–80% of nominal, surface the state on PG or telemetry, and log the event so maintenance can resolve root causes later.
How do fault classes map to system responses (cut-off, retry, hiccup, log-only)?
Map Class A to immediate cut-off and latch, Class B to limited retries or hiccup with counters, and Class C to log-only with optional debounce. Tie each class to thresholds and timers, then propagate a concise code over PG, FAULT, or telemetry. Ensure counters are sticky across resets, so recurring issues trigger service workflows.
What telemetry is most useful for service analytics?
Prioritize trip code, rolling counters, temperature, ILIM setpoint, OVP or UVLO snapshots, and on or off time stamps. Include last enable source, last disable reason, and debounce or blanking settings. Buffer at least several recent events for upload. With this minimal set, service teams can separate real faults from environmental or usage artifacts.
How do I bind remote disable to risk signals without false service outages?
Combine multiple indicators, for example temperature, state of charge, and load pulsation, and require persistence or majority voting before asserting remote disable. Add a minimum on time and release hysteresis to avoid flapping. Keep EN pin as the hard override, while digital disable follows logic policies that can be tuned per deployment.
What’s the safe polling and logging cadence for I²C or PMBus?
For steady monitoring, 1–10 Hz is typical and minimizes bus contention. Use event-driven pushes for trips and state changes, with a small local buffer to survive brief power or link losses. Avoid tight polling inside interrupt service routines; batch reads on a timer and snapshot thresholds whenever you change configuration values.
How should a field-replaceable eFuse store and expose fault history?
Persist a compact record in EEPROM or flash: last trip class, counter, temperature snapshot, and a time basis. Expose a read-only window at power-up for intake diagnostics. Make counters sticky across brownouts but clearable under authorized service actions. This preserves evidence for repeatability analysis while enabling clean returns to normal operation.
What is a safe soft-unlock workflow after a locked FRU is inserted?
Authenticate the FRU, read its history, and confirm the lock cause. Authorize a technician-only soft unlock, then allow a single controlled enable with reduced ILIM or extended blanking. Recount events from zero while retaining the pre-unlock log for audit. If a new trip occurs quickly, reassert the lock and recommend replacement.
How do I prove that a user-reported failure is repeatable versus transient?
Use rolling counters within a defined time window and correlate with temperature or load telemetry. Capture PG or FAULT pulse widths to distinguish spikes from sustained trips. Compare threshold snapshots before and after events. If repetitions cluster under specific conditions, escalate to root-cause analysis; otherwise, treat as environment or handling anomalies.
How do I specify the diagnostic tier in the BOM to avoid wrong substitutions?
Add explicit language: diagnostic tier equals or exceeds the original, interface must match, and telemetry or remote disable cannot be downgraded. Include acceptable alternatives limited to the approved brands list. Require threshold mapping updates in the change order. Reject parts that only provide PG when the design calls for classed faults or telemetry.
What AEC-Q and packaging notes matter for serviceable eFuse modules?
Confirm AEC-Q grade, temperature range, and lifetime testing relevant to your environment. Choose packages with manageable thermal resistance and solder reliability on your stack-up. Prefer footprints with pin compatibility across siblings to simplify FRU stocking. Add readable markings or IDs to support intake diagnostics and traceability during field replacement workflows.
How do I validate cross-brand alternatives without breaking diagnostics?
Build a mapping sheet for thresholds, register names, and PG or FAULT semantics. Reproduce enable or disable flows, trip counters, and event logs end to end. Verify telemetry fields and units against your cloud schema. Run a short pilot with buffered uploads and audit logs before broader rollout, then update the approved alternates list.
