1) Problem & Page Intent: “Flash drains VSYS while charging”

This page explains a very specific charging-domain problem: when a high-current flash/LED boost fires while the device is charging and the input source (USB / adapter) is limited, the system rail (VSYS) can dip and cause MCU resets, camera freeze, and log loss. This is not a generic LED or lighting topic, and it is not a BMS master topic — it belongs under Charging → power-path / system-priority → flash event coordination.

In real products we often see this stack of conditions: (1) USB can only source 0.5–1 A, (2) the device is already charging, (3) the user triggers a flash or camera capture, (4) the charger keeps drawing current because it has no system-first / power-path logic, so the flash booster and the charger pull from the same limited input. Result: VSYS dips → MCU brown-out → user-visible glitch.

Therefore this page focuses on event coordination: the flash path and the charger power mux must be aware of each other. It is not about boost-efficiency tuning, and not about MOSFET selection in isolation.

• Root cause 1 – Input power is limited: USB/adapter cannot feed charger + system + flash at once.
• Root cause 2 – No system-priority power-path: the charger does not automatically give VSYS higher priority during surges.
• Root cause 3 – No pre-notification: the flash event is not announced a few ms earlier, so the charger has no time to fold back.

Conclusion of Chapter 1: if flash, charger, and power-path do not talk to each other, VSYS will dip. The rest of the page shows how to make them talk.

2) System Topology & Roles: “Who owns the input, who owns VSYS”

In charging-domain designs, the input source is usually single and limited, but the load branches are multiple: (a) charger (sometimes with system power-path), (b) system rail VSYS, and (c) a high-current flash/LED booster. Even if the schematic shows “flash from VBAT”, all these branches still depend on the same input quality. That is why the charger’s power mux / system-priority function must participate during flash.

We can classify the common layouts into three buckets: 1) flash from VBAT (needs charger assist), 2) flash from VSYS (needs power-path priority), 3) flash directly from input (needs input-awareness).

If your charger does not have a power-path / system-first architecture, then all flash-time actions (foldback / suspend / priority) must be done in firmware — that is slower, less predictable, and harder for purchasing to keep consistent across replacements.

3) Flash Event Timing & Pre-Notification

When a high-current flash / LED booster fires while the device is charging from a limited source, the charger cannot reduce its current instantly. Its loop needs time, and so does the power mux to apply system-priority. This is why the flash path must tell the charger / power-path a few milliseconds before the actual flash event. If this pre-notification is missing, most brown-outs will not be from lack of input power but from late current foldback.

A robust implementation therefore has this timing pattern: T − 3 ms: charger folds back → T0: flash booster fires → T + 2 ms: VSYS is sampled → T + X ms: charger ramps back in steps.

Notification sources

• From the application processor: the AP knows a capture/flash is coming, so it asserts a GPIO / I²C command 3–10 ms earlier to request charger current foldback.
• From the flash driver itself: many flash drivers expose a “charge complete / ready to fire” pin; this can be routed back to the charger or to a tiny controller.
• From a small logic / Melexis / tiny MCU: it detects that the flash capacitor is about to discharge and pulls a CHG_SUSP / CHARGE_LIMIT line before the surge.

These three sources all serve the same goal: give the power-stage time to reallocate power to VSYS before the flash surge.

Choosing the pre-notification time depends on: (1) the charger loop response time, (2) the size of the VSYS capacitor, (3) the peak current of the flash. Faster chargers and larger VSYS capacitors can work with shorter notice; slow loops with small capacitors require 3–5 ms.

If pre-notification is not possible, then the design must fall back to hardware hardening: larger VSYS capacitance, a faster power mux, or a staged flash current. But the event-driven approach is preferred because it is repeatable and can be logged.

4) Charger Power Mux Behavior During Flash

Even if your charger already includes a power-path / power mux, it may still let VSYS dip if it does not react to the flash event. During a flash, the mux must temporarily become system-first: give the limited input to VSYS, reduce or pause IN→BAT, and if needed allow BAT→SYS. Without this event-driven switch, the mux only does static source selection and cannot protect VSYS against sudden surges.

Two useful strategies

Inside the charger/power-path we can describe it as three flows that must be rearranged during flash: IN→SYS, IN→BAT, and BAT→SYS. The flash event should de-prioritize IN→BAT and, if the battery is healthy, allow BAT→SYS to help the rail.

If the design uses two discrete load switches to create a mux, this is acceptable, but both switches must be controlled by the same flash-event signal; otherwise one path may still be on and VSYS will dip.

With a true power-path, the system can ride through the flash with only a temporary reduction in battery charge. Without it, the only option is to lower the entire input current, which can still cause a visible VSYS dip. Also note: this is a local path switch and does not renegotiate USB-C/PD contracts.

5) Brown-Out & Ride-Through Design

Even with pre-flash current reduction (Chapter 3) and system-priority power muxing (Chapter 4), some products will still see short VSYS dips — for example when the user fires flash during charging from a very weak USB source, or when flash overlaps with a TX/modem surge. This chapter adds the third defense layer: local ride-through energy and battery backfeed so that VSYS can stay above the MCU brown-out level for 1–10 ms.

Think of it as a 3-layer shield: (1) event-time current reduction, (2) instant system-priority, (3) short hold-up with capacitor or BAT→SYS. If layer 1 is late and layer 2 is incomplete, layer 3 must still protect application code, logs, and camera pipeline.

• Layer 1 — Pre-limit (T − a few ms): charger folds back / suspends before flash.
• Layer 2 — System-first at T0: power mux sends limited input to VSYS, reduces IN→BAT.
• Layer 3 — Ride-through (T + 1…10 ms): VSYS is supported by local caps or battery backfeed until currents settle.

The MCU brown-out level must be configured against the real flash waveform. If MCU BOR is set higher than the “flash-dip” level, even a 150–200 mV wobble will reboot the system and engineers may wrongly debug firmware while the root cause is power.

When temperature is low (automotive, industrial), effective capacitor value drops. Margin the capacitance or shift more work to battery backfeed. If the charger/power-path supports BAT→SYS, the ride-through capacitor can be smaller.

The key message of this chapter: when coordination is not sufficient, add energy. Ride-through lets the rest of the system be less perfect.

6) Thermal, Duty, and Recurrent Flash Management

Flash firing does not only draw current — it also dumps heat into a board that may already be hot because of battery charging. If the charger is in thermal regulation and flash keeps coming, VSYS can oscillate and the user may report “flash got weak”. The fix is to bind flash duty and charger current to the same thermal signal and to flash frequency.

A good rule is: only allow the charger to return to full current when the gap between two flash events is long enough (for example > 200 ms). Otherwise the charger should stay in a reduced-current state to avoid a “flash → full charge → flash → full charge” sawtooth on VSYS.

Thermal / duty collaboration rules

• Three thermal triggers: (1) battery/pack NTC over limit, (2) charger enters thermal regulation, (3) flash/LED switch over-temperature.
• Single action: if any of the above is hit → lower flash duty/peak AND lower charge current.
• Shared sensing: flash driver and charger should read the same board NTC, so they do not work against each other.
• Frequency-aware charging: when flash events are closer than 200 ms, hold the charger in a partial-recovery state.

With this chapter, recurrent flash (camera bursts, inspection strobes, security beacons) will no longer fight with the charger. Both power flows listen to the same temperature and to the same timing rules, so VSYS remains calmer.

7) Faults, Reporting, and Host Interaction

This chapter makes flash-related power problems visible. Instead of a silent MCU reset, the system should log: “a flash was fired”, “the charger did/did not fold back”, “VSYS dipped to N mV”, and “input was limited”. That way, manufacturing, field service, and your BMS-layer logging under the Battery Charging / Gauging / Protection / BMS domain can tell what happened.

Typical flash-related power faults

Which faults go to BMS, which stay local?

Only user-visible or field-debug-critical faults should go to the main BMS / host log. Timing/tuning-level misses stay in the local MCU ring buffer.

• Go to BMS / host: VSYS actually dipped below safe level; flash was blocked; long-term input-limited; thermal caused flash/charge derate.
• Stay local: foldback was 1 ms late; flash rate nearly hit limit; VSYS dipped but stayed above MCU BOR.

With this fault path, manufacturing can capture “occasional reset during flash” and field teams can reproduce it by reading those four registers right after the flash.

8) Seven-Brand IC Mapping (Charging–Flashing–Coordinated)

This section maps the seven brands you are using — TI, ST, NXP, Renesas, onsemi, Microchip, Melexis — to the two sides of this page: (1) flash / LED / high-current booster devices and (2) charger / power-path / system-priority devices. The goal is not to repeat datasheets but to answer “can I mix TI flash with ST charger” and “what signal must I add”.

Rule of thumb: Same-vendor = simpler validation. Cross-vendor = event signal needed. Keep the pre-notify / suspend line so timing from Chapters 3–4 remains valid.

This mapping chapter stays short on purpose — it is for procurement and for fast cross-vendor answers. Timing, pre-notify, and VSYS protection still follow Chapters 3–6.

9) Validation, Test Scripts, and Seven-Brand Examples

This chapter turns everything from Chapters 1–8 into lab-executable validation steps. The goal is to prove, on real boards, that “when a flash / LED booster fires during charging from a limited input, the charger actually folds back and VSYS does not brown-out”. Every test case must capture the same set of signals so logs can be compared across brands and across charger generations.

1. Common measurement set (all scenarios)

For every flash-related test, capture at least the following quantities:

• VIN — input voltage before/during flash (to detect input limitation).
• VSYS — system rail, must capture minimum value.
• VBAT — to see if battery is backfeeding VSYS during the flash.
• I_CHG — charger current; must show foldback then recovery.
• I_FLASH — flash/LED booster current pulse (peak + duration).
• Temp / NTC — board or pack temperature, to correlate with thermal regulation.
• Fault / INT pin — to log “flash blocked”, “input limited”, “charger suspended”.

2. Four mandatory test scenarios

3. Capture window & pass/fail criteria

Because charger foldback and power-path switching are not instantaneous, all oscillograms must cover both sides of the flash event:

• Capture window: at least ±10 ms around the flash → ≥ 3 ms before, ≥ 7 ms after.
• VSYS limit: VSYS must not drop below 3.0 V, or below (MCU BOR – 0.1 V) if the MCU has a different BOR.
• Charger recovery: I_CHG must start to recover in 5–10 ms after flash ends. If not, log it.
• Event logging: If VSYS goes below target, log the four registers from Chapter 7 (FLASH_EVT, CHG_SUSP, VSYS_MIN, THERM_STATE).

4. Seven-brand validation listing (what to measure on each)

Below is an execution-oriented listing — which side to use for flash, which side for charger/power-path, and what the validation should prove. Replace the part numbers with the actual PNs you stock, but keep the measurement logic.

Note: keep the ±10 ms waveform rule for all seven brands so cross-comparison stays meaningful.

Recommended topics you might also need

• Single-Cell Switching Charger (Buck/Boost)
• USB-C Sink + Charging Coordination
• Supercap Charger / Balancer
• Ideal Diode / Power Mux for Battery
• Primary Protector / Pack FET

10) Frequently Asked Questions (Flash × Charger × Power Mux)

This FAQ only answers questions from this page’s scope: firing a flash / LED booster while the product is charging from a limited source and a power-path or charger must make way for VSYS. It does not cover USB-C / PD contract, multi-cell balancing, or generic fast-charging negotiation.