← Back to: Battery Charging / Gauging / Protection / BMS
Positioning in the Charging Domain
This page describes a charging-domain safety MCU. It is not the vehicle-level BMS controller and not the high-voltage insulation or pack-FET controller. Its duty is to sit inside the charging branch and to turn several measurement sources into a single, reliable charge decision.
In a real BMS, the charger IC, the AFE/cell monitor, the NTC line and even a hardware comparator can all report status on their own, but they do it as single sources. To meet automotive or industrial safety goals you need multi-source measurement + voting + self-test, and this consolidation can only be done by the MCU.
Charging-domain logic asks: “Is it still safe to inject energy?”. Pack/protection-domain logic asks: “Do we have to physically isolate the pack?”. Mixing them in one controller or one page makes it harder to control BOM rules, so this chapter stays in the charging branch.
Inputs to this MCU include the AFE’s digital interface (cell and pack voltages, alerts), the MCU’s own ADC channel for cross-check, one external window/comparator for high-confidence thresholds, and the battery/board NTC. Outputs go to the charger/power-path controller (CHG_EN, limit pins, thermal input) and to the system/logger so that every safety decision is visible.
Boundary for this page: no pack FET, no HV insulation/leakage, no pre-charge, no discharge-side FET control. Those belong to separate BMS protection pages.
Why AFE + Charger Is Not Enough
AFEs can raise OV/UV/OT flags and charger ICs can terminate or suspend charging, but these are independent devices looking at possibly different electrical points. What we need for a charging BMS is a device that listens to all of them and decides once. That is the role of the charging-domain safety MCU.
The classic conflict is “AFE reports over-voltage” while the charger only sees a valid VBAT/VSYS and continues its normal CC/CV sequence. Without a supervising MCU, there is no arbitration and no way to convert this into a uniform action such as “charge limited” or “charge denied”.
Another frequent issue is the temperature/NTC line. AFE may treat an open/short NTC as a serious fault, while the charger just derates. A safety MCU can encode your real rule: “if sensing is doubtful, do not fast-charge.”
Firmware or register mismatches between AFE and charger revisions are also common in small-batch builds. A safety MCU becomes the single place that knows the latest policy and can log and report what action was actually taken.
Architecture Options for a Safety-Capable BMS Master
A charging-domain safety MCU does not have to be implemented in only one way. To cope with small-batch builds, supply-chain shifts and cross-brand replacements, we keep three valid architectures in scope: (A) single safety MCU, (B) generic MCU plus external comparator/ADC, and (C) safety MCU plus sensor/safety companions. Each one is acceptable for the charging domain as long as you preserve redundant measurement, voting and BIST/self-test capability.
Your purchasing users will ask three things: “Can I swap it?”, “If I swap, do I need to add external parts?”, and “If I add them, is this still economical?”. This chapter answers exactly these questions and pre-allocates slots for the seven brands (TI, ST, NXP, Renesas, onsemi, Microchip, Melexis) so that part numbers can be filled later without breaking the page structure.
Option A — Single Safety MCU
TI Hercules, NXP S32K, Renesas RH850, ST safety MCUs.
Pros: safety docs, BIST and diagnostic libraries are available; shortest path to a high-integrity charging head.
Cons: higher price and lead-time pressure. If replaced, the new device must offer the same BIST and dual-ADC capabilities.
Option B — Generic MCU + Ext. Comparator / ADC
STM32, dsPIC, SAM + window comparator + external ADC.
Pros: good for urgent or shortage builds.
Cons: every external device must be documented in the BOM’s safety remark; timing must be aligned before voting.
Option C — Safety MCU + Companions
Safety MCU + Melexis / onsemi / Microchip sensor ICs.
Pros: sensor loss can be detected; easier to swap sensor brands later.
Cons: longer BOM and two separate lead-times to track.
Redundant ADC / Comparator Strategy
This is the core of the page. A charging-domain safety MCU is meaningful only if it can compare two fresh measurements of the same critical quantity. If a part change removes the second ADC or shares the reference with the first one, the whole redundancy plan collapses. That is why this chapter must be visible to purchasing, EMS and test partners.
Two measurement sources are considered for every critical charging parameter: (1) the AFE’s digital path — the one that already survived the high-voltage front end, and (2) a local MCU ADC path or an external ADC/window comparator path. Voting happens only when both values are recent, properly tagged (timestamp/sequence) and uncorrupted (CRC).
Quantities that must be redundant in charging: Pack voltage, Charge current, Cell / pack temperature (NTC), and Board temperature. Losing redundancy on any of these four means the safety MCU must at least enter “charge limited” mode.
Which quantities need redundancy
Pack V (OV/UV decisions), Charge I (limit vs deny), Cell/Pack Temp (NTC line health) and Board Temp (local hotspot detection). If any of these lose the second path, charging must be degraded.
Data freshness rules
Voting requires same-cycle data. Use timestamp, sequence or CRC in the AFE frame; re-sample MCUs own ADC immediately before voting to avoid “yesterday’s AFE, today’s MCU” mismatches.
Action ladder on mismatch
1) re-sample; 2) if still mismatch → charging current limit; 3) if mismatch persists or sensor considered bad → charge denied + report to system MCU/logger.
BIST / Self-Test / Startup Diagnostics
Charging-domain controllers may stay online for hours or days. A single power-on test is not enough. We therefore define two layers of diagnostics: Startup BIST (run at power-on / before entering supervised charging) and Periodic / event-driven self-test (run while the charger remains connected). If either layer fails, the MCU must degrade charging and log the reason.
Startup BIST confirms that the MCU can measure, can talk to the AFE and can actually pull the fault / charge-control lines. Periodic self-test confirms that these capabilities have not silently degraded while the system is on charge.
Important: “Test only at power-on” is risky in a charging system. A charger that stays online for a long time must re-test itself at defined intervals or on charging events.
| Item | Method | Expected time / phase | Fail action |
|---|---|---|---|
| RAM test | March / pattern over safety RAM block | Power-on | Do not enter charging; log |
| Flash CRC | CRC over image / safety region | Power-on (before comms) | Stop charging domain; request service |
| ADC channels | Known reference / shorted channel read | Power-on + every X min | Enter current-limited mode |
| AFE I²C/SPI link | Read ID / status / alert register | Power-on + on comms error | Charge denied; log AFE comms fail |
| Fault line | MCU drives low → charger sees fault | Power-on + on charger plug-in | Charge denied; must be fixed |
Note for purchasing / EMS: if a safety MCU is replaced by a non-safety MCU, all equivalent BIST items must be re-created with external parts and documented in the BOM safety remark.
Fault Voting & Escalation Model
With a charging-domain safety MCU we can have three simultaneous sources of truth: a hardware comparator (closest to the real voltage/temp), the AFE (full cell/pack view), and the MCU ADC (local confirmation path). This chapter makes it explicit how to vote when these sources disagree, and how to escalate from “just limit” to “deny” to “lock until cleared.”
Priority is fixed: Hardware comparator > AFE > MCU ADC. If HW and AFE both point to a fault, the MCU must not overrule. If none of the three agree, the MCU must re-sample immediately before taking action.
This model is what your readers will copy into their BOM remark to tell purchasing: “this board uses 3-source voting, do not remove the comparator or change AFE thresholds casually.”
Level 1 — Limit
Lower charge current to Imin, keep charger enabled, log the mismatch, and request immediate re-sampling. Good for transient or communication glitches.
Level 2 — Deny
Pull CHG_EN low, notify system MCU, and store three-source values (HW, AFE, MCU) with timestamp; used when two sources agree on a real fault.
Level 3 — Lock
Keep charging disabled until a higher-level controller, a service tool or a factory reset clears the fault; suitable for automotive/industrial long-online packs.
BOM remark template: “This board uses 3-source charging fault voting: HW comparator > AFE > MCU ADC. Do not remove the comparator, change AFE thresholds or downgrade the MCU ADC without updating the voting table and re-validating escalation.”
Charging-Domain Interfaces (EN, Limit, Fault, Telemetry)
This section lists all signals between the charging-domain safety MCU and the rest of the charging branch: charger IC, AFE, system MCU/logger and optional pack/protection logic. The goal is to make direction, default level, safe level and polarity explicit, so that small-batch procurement cannot flip them silently during MCU or charger substitutions.
Rule for this page: if the safety MCU does not boot or does not finish BIST, charging must be disabled. EN lines must be defined as safe-low (or safe-open with pull-down) unless the paired charger absolutely requires active-high with pull-down at charger side.
| Signal | Direction | Normal state | Safe state (MCU dead) | Used with ICs (PN) | Procurement note |
|---|---|---|---|---|---|
| EN_CHG / CHG_EN | MCU → Charger | High = allow charge | Low = block charge | TI BQ25731 / BQ25750 / BQ25756, onsemi FAN54120, NXP system power boards | Polarity must not be flipped when MCU is substituted. |
| ILIM / ICHG_SET (DAC/PWM) | MCU → Charger | Defines charge current | Force to min / disable channel | TI BQ25731, BQ25723, BQ25756; Renesas / NXP discrete charger stages | If PWM is used, keep frequency / duty mapping. |
| THERM_FAULT_IN / NTC_IN | MCU → Charger | Normal temperature window | Force thermal derate / stop | TI BQ25750, TI BQ25756, onsemi charging front-ends | NTC polarity & pull network must be kept. |
| ALERT / FAULT | AFE → MCU | High/idle | MCU interprets low as fault and blocks charging | TI BQ79616-Q1, NXP MC33771C, Renesas ISL78714 | If AFE is swapped, re-test interrupt polarity. |
| DRDY / DATA_RDY | AFE → MCU | Pulsed | If missing → MCU re-samples locally and may limit | BQ796xx, MC33771C, ISL78714 | Do not tie off if MCU changed. |
| I²C / SPI / CAN-FD | MCU ↔ System | Periodic telemetry / events | No telemetry but charging stays blocked | S32K3, RH850, SPC58, dsPIC33CH | Must log source of fault (HW/AFE/MCU) + timestamp. |
| SAFE_STATE / CHARGING_SAFE | MCU → Pack / Protection | High = OK | Low = pack-level safe | Any pack controller or Renesas / NXP safety gateway | Keep level as active-high OK, low on MCU boot fail. |
Interface consistency test: after changing the MCU or the charger IC, run a full high/low sweep on EN, LIMIT, FAULT and SAFE_STATE; confirm the charger reacts only after the MCU has voted and logged.
Small-Batch Procurement & Cross-Brand Alternatives
This chapter documents how to replace the original safety MCU when lead-time or budget issues appear. We define three realistic replacement routes and we make them explicit in English so that purchasing can paste them into the BOM remark: (1) same brand, same safety level; (2) cross-brand with equivalent safety docs; (3) downgrade to generic MCU but re-create safety by adding external comparator and ADC.
Key rule: this page’s BOM remarks are exclusive to “BMS Master MCU (Safety)” and must not be overwritten by other charging sub-pages. Other pages do not mention “dual ADC required” or “interface consistency test”.
Route A → A (same brand)
TI: TMS570LC4357 → TMS570LS0432 NXP: S32K344 → S32K146 Renesas: RH850/P1M-C → RH850/F1KM ST: SPC58NN84C3 → same family lower flash
Keep dual ADC, BIST, and Chapter 7 I/O polarities.
Route A → B (cross brand)
TI Hercules ↔ NXP S32K3 ↔ Renesas RH850 ↔ ST SPC58. Re-run Chapter 5 BIST and Chapter 6 voting because diagnostic registers and alert polarities differ.
Document change in BOM with date, MCU PN and test script version.
Route A → B (downgrade)
Generic MCU (Microchip dsPIC33CH128MP503 / NXP S32K1 low-end) + external comparators (TI TLV1701-Q1 / onsemi NCV33174) + external SAR ADC.
Keep AFE PN (BQ79616-Q1 / MC33771C / ISL78714). Add line in BOM: “external safety devices added to restore redundancy”.
BOM remark examples (English):
1) “Safety MCU changed from <old PN> to <new PN>; re-run Chapter 5 BIST and Chapter 7 I/O consistency test; keep charger EN active-low safe.”
2) “MCU downgraded to non-safety device; added external comparators (TLV1701-Q1) and external ADC for redundant charging measurements; AFE PN unchanged.”
3) “3-source fault voting (HW comparator > AFE > MCU ADC) from Chapter 6 must be re-validated after MCU or charger IC substitution.”
TI: Hercules with BIST → OK; non-Hercules → add external comparator.
ST: SPC58 supply must match automotive temp/grade.
NXP: S32K3 + FS26xx better kept as a pair.
Renesas: don’t downgrade ISL78714 when MCU is downgraded.
onsemi: use NCV29xx / NCV33174 as safety front when downgrading.
Microchip: dsPIC33CH needs external safety devices.
Melexis: sensor only, not a safety MCU replacement.
Validation & Test Hooks for Safety-Oriented Charging
This section turns the safety logic of the previous chapters (BIST, fault voting, interface safety, procurement constraints) into a step-by-step validation checklist. The goal is simple: prove that this MCU actually arbitrates faults and stops the charger, instead of letting the AFE or the charger decide alone.
Focus areas: (1) startup BIST is really logged, (2) injected AFE faults are really voted by the MCU, (3) charger CHG_EN is really controlled by the MCU, (4) sensor removal (NTC) leads to a clear charge-denied state, (5) ADC offsets trigger derating instead of blind stop.
| Test ID | Action (what to inject) | Observe | Pass criteria | Notes (EMS/production) |
|---|---|---|---|---|
| V-CHG-BOOT-01 | Power-up with safety MCU mounted | Log: BIST_OK + time + MCU_PN |
Charging pins remain safe-low until BIST_OK | Re-run every lot if MCU PN from Chapter 8 is changed. |
| V-ALERT-INJECT-02 | Force AFE ALERT low (BQ79616-Q1 / MC33771C / ISL78714) | MCU log shows source=AFE, vote=2-of-3 | Charger CHG_EN goes low only after MCU vote |
If EN goes low first → interface miswired (Ch.7). |
| V-ADC-OFFSET-03 | Apply +2…+5% offset to MCU-side ADC reference | MCU computes “overcurrent risk” | System transitions to “limit / derate”, not full stop | Proves that tuning is not 1-source-only. |
| V-CHG-EN-OVERRIDE-04 | Pull charger CHG_EN low externally |
MCU logs “charger stopped” and pushes SAFE_STATE | MCU does not stay “charging=ON” after charger stop | Needed for EMS to verify harness/line polarity. |
| V-NTC-REMOVED-05 | Remove / short NTC in charging branch | MCU event: temp-invalid → charge denied |
Charger is blocked, log keeps the source=NTC | Use to prove “NTC-driven hotspot derating is REQUIRED”. |
Final rule: if any of the above steps fails after an MCU swap (Chapter 8), charging must stay disabled and a new BOM remark must be issued.
Documentation & BOM Remarks (For Purchasing & EMS)
This chapter writes down the non-removable fields that purchasing and EMS must keep when they substitute the MCU or charger IC in the charging domain. These fields tie directly back to safety features from Chapters 5–9: BIST, dual-path measurements, voting version and safe-state polarity.
Do not replace this charging-domain BOM template with the protection-domain one. Protection-domain pages do not define charger EN polarity, charging-domain voting order, or NTC-derating requirements.
Mandatory BOM lines
1) “Safety MCU or equivalent with diagnostics”
2) “Dual measurement path preserved (AFE + MCU/ext. ADC)”
3) “Charging I/O polarity: EN=active-low safe, SAFE_STATE=low on fail”
4) “Charging fault voting table = v1.0 (Comparator > AFE > MCU ADC)”
SOP additions for EMS
• Run startup BIST on every assembled unit.
• Record result in MCU/system logger.
• If MCU PN is substituted (Ch.8), re-run validation hooks (Ch.9).
• Do not flip charging I/O polarity to “make it work”.
External safety compensation parts
• Comparator: TI TLV1701-Q1 / TLV1702-Q1, onsemi NCV33174
• Ext. ADC: automotive SAR, 12–16 bit, isolated or iso-capable
• Keep original AFE PN (BQ79616-Q1 / MC33771C / ISL78714)
English BOM remark to paste:
“This design relies on MCU-level safety diagnostics (BIST, redundant sensing, fault voting) to control battery charging. Do not replace the MCU with parts that lack safety documentation or dual-channel measurement support.”
Request a Quote
FAQ — Charging-Domain Safety MCU
The following FAQ answers only charging-branch questions: why we need a charging-domain safety MCU, how to replace it, what to add when downgrading, and how to write BOM and SOP so EMS cannot silently drop the second measurement path. Questions about HV insulation, pack FETs, or SOH are intentionally out of scope.
1) Why do we still need a safety MCU if AFE and charger can already stop?
AFE and charger each see only one part of the system, so their actions are single-source. The charging-domain safety MCU combines AFE alerts, its own ADC reading and hardware comparators into one voted decision, then stops or derates charging while logging the reason. Without that arbitration layer, you cannot later prove why charging was denied or whether the AFE was lying.
2) Can I replace the safety MCU with a generic STM32 / dsPIC / SAM?
You can, but only if you restore diagnostics externally. A generic MCU must be paired with an automotive comparator and a separate ADC, so the redundant measurement for charging remains available. After substitution, re-run startup BIST and the fault-injection tests, and update the BOM remark to say the replacement was made and tested for the charging domain.
3) If I downgrade the MCU, what external safety parts are required?
Minimum set: one auto-grade window or rail comparator (e.g. TI TLV1701-Q1, onsemi NCV series) and one dedicated ADC channel or SAR ADC so the MCU can cross-check AFE data. Keep the original AFE PN unchanged. This rebuilds the redundant measurement for charging that the original functional-safety MCU used internally.
4) How should the BOM describe the safety MCU so purchasing cannot drop the second channel?
Add an English line such as: “Charging-domain safety MCU with dual-source diagnostics; do not substitute with single-ADC parts.” Follow with: “Dual measurement path preserved (AFE + MCU/ext. ADC).” This text makes it clear to purchasing and EMS that the system depends on two measurement sources, not just the AFE measurements inside the pack monitor.
5) What if EMS flips the charger EN polarity while changing the MCU?
Then the charger might stop before the MCU has voted, breaking the time order we need to prove safety. In a correct build, the charging-domain safety MCU decides first and the charger reacts second. If polarity was flipped, re-run the interface sweep from Chapter 7 and document the corrected polarity in the BOM/SOP so it cannot be flipped again.
6) Do we have to re-run startup BIST after changing MCU, AFE or charger IC?
Yes. Any substitution that affects measurements or fault lines must be followed by a BIST run and a stored log entry. This proves to QA that the charging-domain safety MCU booted, checked its RAM/Flash/ADC and can still talk to the AFE. Keep the BIST result together with the board serial or EMS lot number for later traceability.
7) How do we log fault voting so we can debug later?
For every charge fault, log three things: source values (comparator, AFE, MCU ADC), the voted result, and the action taken (limit or deny). That log is the evidence that a charging-domain safety MCU actually combined multiple signals. Without it, field failures become impossible to trace and EMS may wrongly blame the charger IC for doing the shutdown.
8) In small-batch builds, can I mix TI/ST MCUs with NXP/Renesas/onsemi AFEs?
Yes, cross-brand mixes are common for small MP or urgent lots, but you must re-check alert polarity, EN timing and data-ready behavior. Also restate in BOM that redundant measurement for charging must stay: AFE measurements plus MCU or external ADC. If any of these change, run the Chapter 9 validation hooks before releasing the lot to customers.
9) Which signals must be exercised in factory test to prove the safety path?
At minimum: inject AFE ALERT, watch the charging-domain safety MCU log or vote, and confirm that charger EN goes to the defined safe level afterward. Optionally toggle SAFE_STATE or the logger interface. If this three-step timing cannot be reproduced on the line, then interface wiring, polarity or the substituted MCU is not compliant with this charging page.
10) What documents must suppliers provide for alternative MCUs?
Ask for a safety or diagnostic manual, BIST description, I/O polarity details, and a note on how to keep the redundant measurement for charging (either built-in dual ADC or external ICs). Without those, purchasing might bring in a low-cost MCU that works electrically but removes the validation hooks you need for this charging domain, which is not acceptable.
11) How do we stop EMS from swapping in a cheaper, non-diagnostic MCU?
Put the warning directly in the BOM and the EMS SOP: “Do not replace the charging-domain safety MCU with non-diagnostic devices; if substitution is required, add external comparators and re-run charging validation tests.” Tie the EMS fixture to the expected MCU ID or to the BIST log, so a board with the wrong MCU actually fails the line test.
12) How often should runtime self-tests run in this charging domain?
Run at power-on, every time the charger/power-path is connected, and at a fixed interval such as every 30–60 minutes while the pack sits in charge. That way the redundant measurement for charging is re-verified and you can catch stuck comparators or bad ADC references. Record the last self-test status in the system log for service or RMA purposes.
