A programmable digital LED driver is defined by a register image (what the product “is”), a dimming engine (how brightness changes over time), and read-back evidence (telemetry + fault logs) that makes field issues diagnosable.

This page focuses on the digital plane (bus + registers + telemetry/logs). The power stage can be treated as a separate layer, as long as the digital plane remains measurable, recoverable, and noise-resilient.

This chapter is written as a deliverable: it defines address policy, timing margin, and integrity/recovery rules that keep bus transactions stable under real wiring, capacitance, and noise.

Address planning: strap vs soft address (and multi-device collision rules)

• Strap address: predictable and production-safe; preferred when multiple identical devices share one bus and collisions must be structurally impossible.
• Soft address: flexible but must include a deterministic source of truth (when it is written, who is allowed to write it, and how it is restored after reset).
• Collision rule: if two devices respond to one address, the system must enter a no-write safety mode (stop configuration writes) until the conflict is resolved.
• Scan policy: scanning is for discovery and inventory (read-only); configuration writes should require an explicit match on revision ID (and optional variant ID) to prevent writing the wrong target.

Timing margin: pull-up + bus capacitance + rise time + clock stretching

• Rise-time budget is the real limiter in field wiring. Treat the bus as Rpullup + Cb: as Cb grows (cables, connectors, ESD parts), the edge slows and margin collapses.
• Deliverable requirement: specify a target bus speed together with a maximum allowed Cb (or verified tr) and a recommended Rpullup range.
• Waveform pass/fail: verify tr at TP_SCL/TP_SDA and ensure the HIGH level stays above the input threshold with margin (glitches near VIH/VIL are the common “works on bench, fails in product” cause).
• Clock stretching: treat long SCL-low periods as a first-class spec item. Define host tolerance (timeout), record the worst-case stretch, and design retry/backoff so stretching cannot trigger retry storms.

Integrity and recovery: PEC/CRC, repeated start, ACK/NACK semantics, retries

• PEC/CRC: enable when wiring/noise is not tightly controlled. Integrity must be measurable via counters (PEC failures, retry counters) rather than “seems stable”.
• Repeated start: define whether the target supports it and how the host behaves if a repeated-start sequence fails mid-transaction (abort + recovery path).
• ACK/NACK semantics: distinguish “not-present/not-ready” from “data rejected/busy” from “integrity failure”; each category must map to a different recovery action.
• Retry policy: specify max retries, backoff timing, and a forced escape hatch (device reset or bus recovery) to prevent infinite retry loops.

Treat configuration as a transaction. A write is not complete until the intended image is verified and the active behavior is proven to match (via effective targets and status).

Pages / banks: scalability with explicit targeting

• PAGE/BANK is an implicit state. If host and device disagree on the active page, writes silently land in the wrong place.
• Rule: every configuration transaction must begin with an explicit target page selection and must record that page in the host log.
• Group writes: when multiple channels must be consistent, use a group mechanism (page-wide apply or group commit) rather than sequential live edits.

Atomic update: Shadow → Verify → Apply → Active

• Shadow: a staging area to build a coherent image (multiple fields, multiple registers) without exposing intermediate states.
• Verify: read-back and/or checksum/PEC validation catches “half writes”, bus noise, and addressing mistakes before any change becomes live.
• Apply: a single action that transfers shadow to active, enforcing “all-or-nothing” behavior. A busy/lock flag must gate apply to prevent partial transitions.
• Active: the only truth for runtime behavior; reading effective targets and status must confirm that active equals the intended image.

Evidence fields (minimum)

• Transaction fields: target page, payload length, checksum/PEC status, apply/commit flag, and host-side retry count.
• Read-back fields: revision ID, config CRC (or equivalent), effective targets, and last-error code / busy flag.

Non-volatile storage turns “configuration” into a product promise. The goal is consistent defaults across production lots, safe field updates, and a provable rollback path when writes fail.

Image model: STORE / RESTORE / DEFAULT (without vendor-specific commands)

• DEFAULT image (Factory baseline): the known-good configuration that must remain recoverable under all failure modes. Treat as read-mostly and immutable in the field.
• USER image (Field configuration): optional customer/runtime preferences that may be updated, but must never override the ability to boot safely.
• RUN image (Active/shadow): the working set used during normal operation. RUN may change frequently, but must not trigger frequent NVM writes.
• STORE persists a selected image; RESTORE loads an image into RUN; DEFAULT is the emergency fallback when validation fails.

Brownout risk: why partial writes brick units (or create “silent corruption”)

• Failure mode: power loss during commit can leave metadata updated but payload incomplete (or vice versa). The result is an image that “exists” but fails validation.
• Silent corruption is worse than a hard fail: behavior changes after reboot with no obvious error unless CRC/version/valid bits are checked.
• Minimum safeguards: commit must be gated by a “safe-to-write” condition (no brownout, stable reset cause), and must end with mandatory validation before switching the active image pointer.
• After reset: boot selection must prefer the newest valid image; if CRC fails, it must roll back deterministically to a valid prior image (or DEFAULT).

Endurance and write-rate limits: factory vs field partitions

• NVM is not a cache: frequent commits for dimming behavior, telemetry, or runtime tweaks will consume endurance and raise failure probability.
• Partition strategy: separate “factory baseline” from “field preferences”. Factory partition should be write-protected outside production; field partition must be rate-limited and validated.
• Commit policy: define allowed commit triggers (e.g., commissioning only), and enforce minimum intervals and maximum lifetime commit counts per partition.
• Rollback discipline: never overwrite the only known-good image. Always keep at least one prior valid image in reserve.

Curves and fades are a pipeline problem: commands are interpreted by an engine, converted into a current target, then constrained by clamps and derating. “Linear” must be defined in the domain that matters.

Curve representations: LUT vs segmented linear vs polynomial (concept-level tradeoffs)

• LUT: predictable and calibratable; low-level control can be dense where the eye is most sensitive. Cost is points and storage.
• Segmented linear: compact and stable; good when register space is limited while still allowing “denser low end”.
• Polynomial: few parameters but sensitive to edge behavior and numeric stability. Requires careful bounding to avoid overshoot near endpoints.
• Key engineering point: the curve defines low-light resolution and step visibility, not just a mapping from “percent” to “current”.

Fades: timebase, step strategy, and avoiding visible stair-steps

• Timebase: an internal engine tick is deterministic; host-timed updates can jitter with scheduling and bus latency.
• Step strategy: a constant step size often looks “steppy” at low light. Better strategies densify steps near low levels or use time-normalized interpolation.
• Interpolation: define how intermediate points are computed (nearest / linear between points). Even a LUT needs an interpolation policy for smooth fades.
• Deep dimming stability: use a minimum current clamp to avoid dropouts and a controlled transition through the lowest region where quantization dominates.

Perceptual consistency: current-linear is not visually-linear

• Gamma/log curves are practical tools for “equal perceived steps”. The point is not the math, but the measurable outcome: fewer visible jumps at low levels.
• Define “linear” explicitly: linear in current, linear in perceived brightness, or linear in command scale. The chosen definition must match product expectations.
• Stability knobs: clamp, optional dither, and derating must be placed in the pipeline to avoid unexpected jumps when constraints engage.

A dimming command is not the output. The output is the result of a priority resolver that combines runtime intent with protection and derating constraints. When “writes do nothing” in the field, the missing piece is usually the winning layer and its recovery rules.

Priority ladder (from highest to lowest)

• Hard shutdown: UVLO / OTP / critical fault → effective target forced to 0 (safe state).
• Fault latch: latched short/open/overcurrent → blocks output until clear rules are satisfied.
• Thermal derating: scales down the target (derating factor) to avoid reaching a shutdown threshold.
• Soft constraints: min clamp, slew limit, fade step-rate caps → reshape the target without declaring a fault.
• Runtime intent: manual dim target / fade engine output (the “requested” target).

Soft derate vs hard off: recovery rules decide field behavior

• Soft derate keeps output on but reduces brightness. It must include hysteresis to prevent oscillation near thresholds.
• Hard off forces output to zero. It must define clear conditions (cool-down timer, retry budget) to avoid “never recovers” failures.
• Recovery triggers typically combine: temperature below a release threshold, a minimum time window, and a stable input condition (no UVLO/reset churn).
• Command consistency: after recovery, the resolver should return to the latest valid runtime intent, not an undefined intermediate value.

Debug method: prove the winning layer using four fields

Telemetry is a signal chain, not a list of numbers. Trust depends on sampling path, calibration, filtering, update timing, and explicit freshness/range flags. Use depends on thresholds and trends that can be executed locally by the host.

What to measure: categories that explain behavior

• Supply health: VIN/VOUT indicates margin to UVLO and identifies sag events that change effective output.
• Output proof: ILED (and duty/target indicators if available) proves whether the effective target is being met or constrained.
• Thermal context: temperature explains derating engagement and proximity to shutdown thresholds.
• Energy estimate: power estimation supports trend-based warnings and detects abnormal load or thermal drift patterns.

How to trust it: raw vs scaled, calibration, filtering, and freshness

• Raw vs scaled: raw codes (ADC counts) expose clipping and offset; scaled values apply units and calibration coefficients.
• Calibration coefficients: define absolute accuracy; coefficients should have an identifier or revision for traceability.
• Filter window: reduces noise but adds latency; the host must interpret values in the context of the filter and update period.
• Update period and stale flag: a fresh-but-late value is different from a stale value; both must be detectable.
• Range/clip flags: if a channel is saturated or out-of-range, scaled values may be misleading even if they look stable.

How to use it locally: threshold alerts and trend warnings (no cloud required)

• Threshold alerts: VIN near UVLO, temperature near derate/shutdown, ILED deviation from effective target beyond tolerance.
• Trend warnings: rising temperature slope, repeated VIN dips, or increasing power estimate over time (indicates cooling degradation or load change).
• Reliability checks: ignore updates marked stale; down-rank channels with clip flags; require persistence across multiple fresh samples.

A fault that cannot be explained becomes a product failure. The goal is traceability: a compact status view for “what is wrong now,” plus a durable history of “what happened first” and “what the system looked like at that moment.”

Flags: transient vs latched (and why both matter)

• Transient (“seen”) indicates an event occurred at least once. It is essential for intermittent issues that self-recover before anyone reads status.
• Latched (“blocked”) indicates recovery is intentionally prevented until clear conditions are met. It protects safety and prevents rapid re-trigger cycles.
• Interpretation rule: a clean “current state” without history cannot explain field reports. A durable “seen” bit without a current latch cannot explain whether the device is still in a faulted condition.

Multi-fault concurrency: avoid losing the root cause

• Status word/byte as a full bitfield: preserves the “many things can be true” reality.
• Fault code as a quick classifier: points to the dominant category for fast triage.
• First-fault pointer: captures the earliest trigger so later secondary effects do not overwrite the root cause.
• Event log (ring): records fault ordering so concurrency can be replayed rather than guessed.

Event logs: ring buffer + snapshot fields that actually diagnose

An event log should not only store “what fault happened,” but also “what the system looked like when it happened.” A minimal snapshot typically includes input margin (VIN/VOUT), thermal context (temperature), and control context (requested target vs effective target). These three are usually enough to distinguish override-driven behavior from genuine electrical faults.

Clear strategy: preserve evidence without blocking recovery

• Clear-on-read: simple, but risky for diagnostics because evidence disappears when polled. Best limited to counters or non-critical transient summaries.
• Explicit clear: preserves evidence until a deliberate action clears it. Best for latched faults and first-fault capture.
• Power-cycle clear: can mask repeating issues if evidence vanishes on every restart. Use carefully, and prefer retaining first-fault/log history across resets when possible.

A robust control bus must remain recoverable in noisy environments. The engineering goal is not “never errors,” but “errors are detectable, counted, and recoverable without human intervention,” including isolation boundaries and hot-plug disturbances.

EMI failure signatures that break products

• SCL glitches: narrow pulses or spikes that look like extra clocks to state machines.
• SDA bit flips: unintended data transitions causing corrupted bytes or false start/stop interpretation.
• Hung bus: SCL or SDA held low (often SDA) so no new transaction can begin.

Recovery ladder: detect → free the bus → re-sync → escalate if needed

A practical recovery sequence starts with stuck-low detection (line low beyond a safe time budget), then applies clock-pulse recovery to release a device stuck mid-bit, and finally issues a STOP to force the bus back to idle. If the bus remains hung, escalation uses a device reset line or watchdog strategy.

• Step 1 — detect: SDA (or SCL) low longer than a defined threshold → declare “hung.”
• Step 2 — recover: drive 9 clock pulses to advance a stuck receiver through remaining bits.
• Step 3 — re-sync: generate a STOP condition (SCL high while SDA rises) to return to idle.
• Step 4 — escalate: if still hung, apply device reset or rely on watchdog to prevent permanent deadlock.

Isolation boundary effects (interface-level only)

• Propagation delay reduces timing margin and can reshape edges seen by the bus.
• Pull-up placement matters across the boundary; the “bus” can behave like two segments with different rise behavior.
• Bidirectional limits can affect edge cases (including recovery pulses and any stretching-like behavior), so recovery must be validated across the isolation path.

This gate-based plan validates a programmable digital LED driver from first contact to diagnosable failures. Each gate defines what must be proven, the two waveform groups to capture, and pass/fail criteria that can be reused in R&D bring-up and production.