← Back to: Battery Charging / Gauging / Protection / BMS
Battery Black-Box Logger (Charging-Domain)
This page focuses on charging-domain black-box logging — capturing what happened during charging cycles (state transitions, thermal derating, current limiting, power-path arbitration), so service teams can read the last N events and decide whether the issue came from the battery, the adapter, the environment, or the user load.
Why do we need a dedicated logger if the charger IC already exposes status and fault bits? Because most charger ICs only tell you the current condition, not the history. A charging-domain black box keeps short, service-oriented records that answer “what actually happened during the last few charges?”.
It is not a SOC/SOH logger, not an eFuse/protection logger, and not a vehicle-level flight recorder. It only watches the charging path.
- Not SOC log → state-of-charge evolution stays in the gauging line.
- Not protection log → pack/open/short events stay in the protection line.
- Charging-only → CC/CV/termination/power-path anomalies.
Typical placements:
- Portable / wearable / medical devices that see changing adapters.
- In-vehicle 12 V battery maintenance where cabinet temperature is high.
- Small energy/storage modules that charge in hot racks.
- Lab / small-batch validation where charger IC is being swapped.
Why service teams need it more than hardware? Hardware can often reproduce the fault on bench; field teams cannot. They need to read “the last N charging attempts” to know whether the fault was thermal, input-side, or load-induced.
entered CC then dropped after 2 s; entered CV but current stayed low because system pulled VSYS; JEITA derating triggered but user never noticed; USB-C/adapter unstable and restarted several times.
Charging Event Hooks to Log
Once we freeze the event set, implementation is just polling the charger, translating vendor-specific status bits into these normalized events, and committing them into a nonvolatile buffer. This chapter defines that event set.
Mandatory events (always log):
CHG_ATTACH— power/adapter/USB-C sink detected and accepted.CHG_START_CC— charger entered constant current phase.CHG_START_CV— charger transitioned to constant voltage.CHG_TERMINATED— normal end-of-charge or termination current met.CHG_RECHARGE— charger restarted after voltage drop.CHG_ABORTED— watchdog, unstable VBUS, user-forced detach.
Conditional events (log if available in silicon / system):
THERMAL_REG— JEITA or internal thermal regulation was active.INPUT_CURRENT_LIMIT— adapter or port could not deliver configured current.POWER_PATH_PRIORITY— system rail took priority (VBAT ↔ VSYS arbitration).SAFETY_TIMER_EXPIRED— safety timer or charge watchdog fired.BATTERY_NOT_PRESENT / NTC_OPEN— battery missing or NTC disconnected.
ts (tick or RTC), evt (one of the above), T (charger or external NTC), I_chg (actual or configured), V_in, V_bat, src (ic_reg / mcu_adc / ext_ntc).
Do the normalization once at the MCU level, not at the service tool.
Data Point Design: Cycles, Peak T/I, Anomaly Timestamps
Logging only event names is not enough. Service teams need to see how many times a charge was attempted, what the temperature/current peaked at, and when exactly an anomaly occurred. This section defines how to attach counts, peaks and timestamps to each charging event so field engineers can tell whether the board was always hot or just occasionally throttled.
Cycle definition. A charge can be:
- full cycle: CC → CV → terminate completed, battery considered charged.
- partial cycle: CC started but was interrupted by thermal/input drop/user detach/safety timer.
This distinction lets you see “5 attempts, 0 full” instead of just “5 charges”.
Peak temperature (T_peak). Always prefer the charger IC’s own thermal/derating indication. If unavailable, fall back to an external NTC read via MCU ADC. Store it as:
When JEITA was the cause, record which band was active to show it was normal derating, not IC self-heating.
Peak current (I_peak).
- IC supports actual charge current read-back → record actual.
- IC does not support read-back → record configured value and a flag.
Timestamp source. Without RTC, use MCU tick; with USB-C/PD, start from PD session time; during export, re-base ticks to real time on PC/app.
Architecture and Implementation Options
This feature does not require a dedicated “logger IC”. It can be built today from an ordinary charger IC + a small MCU that polls status/fault registers + a piece of nonvolatile storage. Below are three common builds and how to choose among them.
Key questions to answer:
- Can the charger’s own status registers survive power loss? (usually no)
- What polling interval will guarantee we don’t miss short thermal/input-limit events?
- Where should logs live — MCU internal flash, external EEPROM/FRAM, or system-level memory?
- How will an upper BMS/host tool read these records — I²C, UART, USB-C, CAN/LIN?
Architecture A — Charger IC + MCU polling + MCU flash (lowest BOM)
- MCU polls charger status/fault every X ms/s.
- On change → normalize event → write to internal flash.
- Do basic wear leveling.
- Best for dev boards, portable devices, small batches.
Architecture B — Charger IC + MCU + external EEPROM/FRAM (recommended)
- Logs survive power loss.
- 32–128 full records possible.
- Service teams can read storage directly.
- Cost slightly higher but predictable for small-batch runs.
Architecture C — System-level PMIC / BMS MCU logger
- For multi-charger / power-path / dual-battery systems.
- Unified timestamp source (RTC / host / CAN time).
- Can log “charging slowed because system took power”.
- Can expose logs via CAN/LIN/UART/USB-C.
log_ver=1.0) so firmware upgrades don’t break the service tool.
Vendor-to-Logger Mapping (TI / ST / NXP / Renesas / onsemi / Microchip / Melexis)
The goal is to keep your charging-domain black-box logger usable even when the front-end charger IC changes. We do this by classifying each vendor into direct status, MCU compose, or sensor assist, and then telling the MCU to export the same logger fields regardless of which IC was used.
Direct status (IC gives enough info)
IC itself exposes charge state, faults, thermal or input-limit flags.
- TI — bq25600C, bq25895, bq24195, bq24192 (charger + power-path, good fault/status)
- ST — STBC03, STNS01, L6924U (status pins + I²C config)
- Renesas — ISL9241, RAA489118 (SMBus/NVDC, well structured)
MCU compose (MCU must assemble events)
IC provides only “I am charging / I am limited” signals, MCU adds cycle_id, T/I peaks, and timestamps.
- NXP — PCA9422, PMIC-with-charger designs (data goes to main MCU)
- onsemi — NCP1850, FAN54120 (industrial/automotive, needs MCU to normalize)
- Microchip — MCP73831/2, MCP73871 (simple chargers, log sits in MCU/EEPROM)
Sensor assist (T feed-in)
Melexis devices add real temperature so the log can say “thermal derating at 63°C” instead of just “thermal”.
- MLX90614 (contactless T)
- MLX90632 (compact, high-accuracy)
- Optionally: other MLX sensors as diagnostic channels
TI.bq25600C.CHG_DONE → CHG_TERMINATED ST.STBC03.THRM → THERMAL_REG onsemi.NCP1850.VBUS_DROP → INPUT_CURRENT_LIMIT
Export always as: log_ver, ts, ts_src, evt, cycle_type, T_peak, I_peak, V_in, V_bat, src_ic
Small-Batch Procurement and Serviceability Strategy
This chapter is for small-batch buyers who will face substitutions. The main idea is: even if the charger IC is changed, the logger fields, version, and export format must stay the same. We write it in the BOM so purchasing will not downgrade the charger to “charge-only”.
BOM remark template (copy/paste):
Preferred ICs (log-rich):
- TI — bq25600C / bq25895 / bq24195
- ST — STBC03 / STNS01 / L6924U
- Renesas — ISL9241 / RAA489118 (multi-cell, SMBus)
Substitute when out-of-stock:
- onsemi — NCP1850 / FAN54120 + MCU logger
- Microchip — MCP73871 + PIC/AVR internal EEPROM
- Melexis — MLX90614 / 90632 as T-channel
Validation checklist:
- 3 adapters → all log
- Thermal / JEITA → at least 1 entry
- Input drop / system power-path → 1 entry
- MCU reset → log persists
- Substituted IC → same CSV/JSON field names
Validation, Read-Out and Field Workflow
This section defines a single, non-overlapping workflow for engineering validation, production test, and field service. Once this is in place, other charging-related subpages should reference it instead of redefining “how to test the logger”.
Engineering validation
Manually force 3 anomaly types and confirm they all land in the log.
- Thermal / JEITA derating triggered
- Adapter / VBUS drop or unstable USB-C
- System-side load steals current (power-path arbitration)
Then read out and check: all 3 were recorded, timestamps are in order, and peak T/I look realistic.
Production / factory test
In the final station, inject a single factory event:
FACTORY_TEST_OK @ ts=0 · fw=1.0 · logger=v1.0Read back once to make sure the logger is enabled. Mark the unit as “Logger: Enabled” before shipping.
Field / service workflow
Use the same export format everywhere. Client view shows only the latest N entries; engineer view exports full CSV/JSON with raw registers.
Interfaces: I²C→USB, UART→USB-C, or BLE short messages — but the JSON/CSV schema must stay the same.
Request a Quote
Charging-Domain Logger FAQ
All questions below are scoped strictly to the charging domain (CC/CV, thermal derating, input current limit, power-path arbitration). They do not cover pack-level BMS, vehicle loggers, or SOC-only histories.
Why do I need a charging-domain logger if the charger IC already exposes status bits?
Charger status bits tell you what is happening right now. A charging-domain logger tells you what happened across the last N cycles. That history shows whether every charge was throttled by heat, input limits, or user load, which is what service teams need.
Can I log only abnormal charge terminations to save memory?
You can store only abnormal endings, but keep at least one normal full cycle for comparison. Without a good sample, it is hard to tell if the unit never reached CV, or if it was always exiting due to thermal or unstable adapters.
How do I generate timestamps without an RTC on the board?
Log using a monotonic MCU tick and include a ts_src field (for example, “tick”). When exporting through USB, UART, or BLE, the host re-bases the ticks to real time. As long as events stay in order, after-sales can still reconstruct the sequence.
What’s the minimum set of events to capture for after-sales diagnosis?
A practical minimum is: CHG_ATTACH, CHG_START_CC, CHG_START_CV, CHG_TERMINATED, CHG_ABORTED, THERMAL_REG, and INPUT_CURRENT_LIMIT. With just these seven, you can explain most “slow charge” and “never finished” complaints from the field.
Can I capture peak temperature from an external NTC instead of the charger IC?
Yes. Read the NTC through the MCU, mark the source as ntc_ext, and store the highest value seen in that cycle. If you also mount a Melexis contactless sensor, save that too — it helps explain enclosure or cabinet heating problems.
How fast should I poll the charger to avoid missing thermal or input-limit events?
For typical charger ICs, a 100–500 ms polling window is enough. In noisy USB-C or dropping-adapter cases, shorten it to 50–100 ms so you catch brief current-limit or thermal flags. Balance the rate with MCU load and nonvolatile write frequency.
Can I store the log in MCU internal flash for small-batch builds?
Yes, but implement basic wear leveling and cap the depth to 10–32 entries. Internal flash is ideal for prototypes and low volume. For exported or long-life products, move to external EEPROM or FRAM so power loss will not wipe the history.
How do I keep the log format stable if I switch from TI to ST chargers?
Do translation in the MCU. Map each vendor’s status or fault to unified events like CHG_TERMINATED or THERMAL_REG, and always export the same CSV/JSON field names. Also write “logger format = v1.0” in the BOM so purchasing cannot change it silently.
Can I log power-path arbitration events (VBAT↔VSYS) as anomalies?
Yes. Log them as POWER_PATH_PRIORITY or similar and attach V_in, V_bat, and I_chg. These entries explain why a board stayed in low current even though the adapter was OK — the system side was taking energy away from the battery charger.
What depth is enough for field returns — 10, 32, or 64 entries?
For consumer or portable devices, 10 entries usually tell the story. For industrial, automotive, or cabinet deployments, 32 is safer. If the device ships overseas and may be serviced months later, 64 entries keeps enough history to see patterns.
How do I protect the log from being erased during brown-out or hot-plug?
Use a two-step commit: write the entry, verify, then mark it committed. Keep a tiny index in EEPROM/FRAM and, for critical events, write a duplicate copy. On the next boot, the MCU can detect incomplete writes and roll forward safely.
How do I expose the log to customers without leaking the whole register map?
Provide a limited public view that lists time, event, and whether the charger was derated. Keep raw register snapshots, source IC names, and internal timestamps for the engineering view only. Both views should still follow the same schema version.
