← Back to: Battery Charging / Gauging / Protection / BMS
Where SBS/SMBus sits in the charging stack
This section clarifies the position of SBS/SMBus: it is not a general battery algorithm channel nor a vehicle CAN diagnostics path. It is the narrow communication path that a charger MCU/PMIC uses to talk to a smart battery pack in order to make safe CC/CV, JEITA and fault stop decisions.
In other words, you are not only buying an energy pack — you are buying a talking pack. If the SMBus command/alarm table changes across vendors or firmware versions, the charging strategy must be updated or downgraded.
Why it belongs to the charging domain
These charging-relevant values originate in the battery pack. The charger cannot safely improvise these values without the pack’s current limits, voltage limits, temperature or alarm state. That is why this page stays in the charging branch of the overall BMS content structure.
Vendor landscape (7-brand scope)
TI often exposes a full SBS command set (classic smart-battery style). ST, onsemi, Microchip frequently expose I²C/SMBus-compatible registers but with reduced or vendor-specific alarm bits. NXP, Renesas, Melexis often originate their data on the measurement/AFE side and forward it to SMBus via their MCU. This is exactly why a cloud-side telemetry mapper is needed.
Non-goals (to avoid cross-page overlap)
This section does not cover SoC/SoH algorithms, vehicle CAN/UDS, pack-FET drive logic, or high-voltage insulation measurement. It only describes the information path that makes charging safe.
BOM remarks (copy/paste):
1) Charger must operate as SMBus/SBS master to retrieve charging-relevant fields.
2) Do not approve packs that cannot expose status/alarm over SMBus.
Charging-relevant SBS/SMBus commands
SBS defines many commands, but a charger only needs a restricted, charging-oriented subset: charge control, status/alarms, environment/temperature and a manufacturer/safety access group. Mixing brands is risky not because the bus changes, but because the alarm table and temperature exposure change.
Command families you must support
Charge control: ChargingCurrent(0x14), ChargingVoltage(0x15). Some packs only provide suggested values, others require the charger to never exceed them.
Status & alarms: BatteryStatus(), AlarmWarning(). Bit meanings are the usual source of cross-brand issues — one vendor’s OT bit can be another vendor’s safety-latched fault.
Environment / temperature: Temperature() plus, for some vendors, a manufacturer-access JEITA zone. If your replacement pack does not expose JEITA, you cannot regard it as equivalent for a JEITA-enabled charger.
Manufacturer / security: used for configuration, firmware/profile updates and lock/unlock. Chapter 5 will hook into this group.
BOM remarks (copy/paste):
1) SMBus pack must support ChargingCurrent(0x14), ChargingVoltage(0x15), BatteryStatus(0x16), and one alarm-capable command.
2) Packs without alarm-capable SBS commands are not approved for JEITA-enabled chargers.
3) If JEITA zone is not exposed, charger must downgrade to fixed-current/fixed-voltage charging.
What this chapter does not cover
• Full JEITA curve design (see thermal/JEITA page) · • USB-C / PD / EPR negotiation (see USB-C sink + charging coordination page) · • SoC / SoH estimation, data-flash logging, cycle-life metrics (see gauge/fuel pages).
Alarm / fault tables the charger must understand
Being able to read SBS/SMBus does not mean the charger understands every alarm bit. Different vendors — and even different firmware revisions of the same vendor — define AlarmWarning bits differently. Therefore, a charger in the charging domain must normalize those bits before executing charge/derate/stop actions.
This is the most sensitive part of this page: if procurement replaces the pack, the alarm table might change. The system must detect this, fall back to a limited/safe/read-only charging mode, and let the cloud/gateway push an updated telemetry mapping.
Common alarm set (minimum safety)
The charger must always recognize these alarms, regardless of vendor or firmware: Over-Voltage Fault, Under-Voltage Fault, Over-Current Charge, Over-Temperature Charge, and Safety Alert / Internal Error. These are the “must-act” alarms.
Vendor-specific alarm set (must be mapped)
Vendor-specific bits like fuse blown, secondary protector triggered, pack-open / pack-insert, or cell mismatch / imbalance cannot be safely consumed by the charger without mapping. They must pass through the telemetry mapper, which converts them into a normalized action level.
Charger-side rules
If a known alarm bit is seen, the charger executes the policy (stop, derate, log). If an unknown or unmapped alarm bit is seen, the charger must immediately fall back to limited / safe / read-only charging and log the event. This makes procurement swaps survivable.
BOM remarks (copy/paste):
1) Charging system must normalize vendor-specific AlarmWarning bits before use.
2) Unknown or unmapped alarm bits must force charger into limited or read-only charging mode.
3) Suppliers must provide up-to-date SBS/SMBus alarm tables for every firmware revision.
Pack identity, serial and traceability for small-batch builds
Small-batch builds often mix packs from TI, ST, NXP, Renesas, onsemi, Microchip or Melexis. They all “work” and all “speak SMBus”, but their alarm tables and firmware revisions may differ. This is why identity and serial must be treated like voltage and current limits — they must be read, logged and compared every time a pack is introduced or replaced.
Once identity is known, the cloud can group devices by vendor/serial/batch and push the correct telemetry mapper profile only to the affected packs.
Identity fields you must read
At minimum read: ManufacturerName, DeviceName, DeviceChemistry, SerialNumber, ManufactureDate, and FirmwareVersion. Without these six fields, you cannot track which batch introduced a new alarm bit or which firmware changed the SBS table.
When to read identity
Read on first power-up or first charge, after every pack replacement, and immediately after an SMBus firmware/configuration update. Then compare against the allowed seven-brand list.
Procurement and cloud linkage
If procurement replaces a pack with another unit inside TI / ST / NXP / Renesas / onsemi / Microchip / Melexis, the system should still be able to read identity. If identity is missing, the device must drop to limited charging and report to the cloud so the mapper can be updated.
BOM remarks (copy/paste):
1) SMBus pack must expose identity, serial and firmware version; non-reporting packs are not approved.
2) Cross-brand replacements must preserve identity fields or provide a mapping profile.
3) Identity must be read at first charge and after every pack replacement.
Firmware update / lock over SMBus (charging-safe version)
Many real deployments try to update or reconfigure the battery pack while the device is charging. If the update happens without identity and permission checks, the pack may reboot, the charger may lose SBS for a moment, and the charging cycle becomes inconsistent. This section defines a charging-safe 6-step sequence so SMBus updates do not break charging.
The key rule is simple: do not perform SMBus firmware/config updates on unidentified packs, and keep the charger in a limited/safe charging mode during the write phase.
Charging-safe rules
During the write/transfer phase, the charger should remain in a limited or low-power charging state. After writing, the charger must re-read the alarm/status table and confirm it matches the expected profile. If the pack does not return the expected content, the device must fall back to read-only charging and report to the cloud.
Vendor differences
TI often uses ManufacturerAccess() to unlock configuration pages. Some MCU-based packs use custom I²C addresses that only look SMBus-compatible. Automotive-grade packs may require stricter write-protect or environmental conditions. This is why identity and permission must be checked before writing.
BOM remarks (copy/paste):
1) Cloud-side telemetry mapping must be updated before using cross-brand alternatives.
2) Do not perform SMBus firmware/config updates on unidentified packs.
3) During SMBus update the charger shall operate in limited/safe charging mode.
Cross-brand register / command mapping (7-brand scope)
Even when all battery packs “speak SMBus”, their command sets, alarm bitmaps and temperature exposure differ. This section defines how to normalize TI, ST, NXP, Renesas, onsemi, Microchip and Melexis SMBus payloads into one charger-visible view using a telemetry mapper. Hardware stays the same — the mapper changes.
This is the place where your 7-brand strategy lands: you can replace packs inside this brand scope, but you must ship a new mapper profile.
Three source categories in the 7-brand scope
1) TI: full SBS, can be used as template. 2) ST / onsemi / Microchip: SMBus compatible but some fields are missing or vendor-specific. 3) NXP / Renesas / Melexis: measurements originate in AFE/MCU and are forwarded to SMBus. The mapper must be able to normalize all three.
When to issue a new mapper
A new mapper profile is required when procurement replaces the pack, when the same brand ships a new firmware that changes AlarmWarning, or when the charger observes an unknown SMBus address or field. Do not hardcode these differences into hardware — keep them in the cloud/gateway mapper.
BOM remarks (copy/paste):
1) SBS/SMBus command differences must be compensated in the telemetry mapper, not in hardware.
2) Cross-brand replacements inside TI / ST / NXP / Renesas / onsemi / Microchip / Melexis require mapper update.
3) SMBus firmware/config updates must bump the mapper profile ID in the cloud.
Small-batch procurement & replacement warnings (SBS edition)
Small-batch builds break SBS-based charging more often than volume builds. The most common pattern is: procurement found a pack that “can talk SMBus”, voltage and capacity look OK, but the pack does not expose JEITA zones or alarm/status in the format the charger expects. This section is written in a more direct tone for procurement and for people doing fast replacements in the field.
Common small-batch mistakes
1) Focusing on voltage/capacity only, without getting the up-to-date SBS/SMBus command/alarm table from the supplier.
2) Seeing SMBus is present, but not matching the command version that the charger firmware was written against.
3) Replacing the pack in the field but not asking the cloud to update the telemetry mapper, so online devices start reporting unknown alarms.
Mandatory BOM constraints
NTC-driven hotspot derating is REQUIRED.
Packs that cannot expose NTC/thermal zones must be treated as downgraded.
Reject packs without alarm exposure.
AlarmWarning / BatteryStatus must be readable over SMBus.
Replacement must be inside 7-brand scope.
TI / ST / NXP / Renesas / onsemi / Microchip / Melexis only.
Procurement note format (copy as cards)
Order only packs exposing ChargingCurrent(0x14), ChargingVoltage(0x15), BatteryStatus(0x16).
If JEITA/temperature zones are missing, charger will run in degraded mode.
For cross-brand swaps, attach the latest vendor alarm table and trigger a mapper update.
Out-of-scope packs must be validated in staging with full SMBus alarm playback.
BOM remarks (copy/paste):
1) Do not approve SMBus packs that do not expose temperature or JEITA zones.
2) Replacement packs must declare alarm/status in the same format or provide a mapper profile.
3) All small-batch replacements must trigger cloud telemetry mapper update.
4) Replacement must be inside TI / ST / NXP / Renesas / onsemi / Microchip / Melexis scope.
BOM remarks & test script hooks
This section consolidates all the charging-domain BOM sentences from this page into a single copy/paste-friendly block. It also lists the test script steps that must be executed to confirm that the replacement pack actually returns SBS/SMBus data in the expected format.
BOM: charging-domain must-haves
Charger / gauge must expose charging state and JEITA zone to edge gateway.
Signed safety metering is required; do not approve ICs without reporting capability.
Cloud-side telemetry mapping must be updated before using cross-brand alternatives.
Devices that only support fixed-temperature charging must NOT replace NTC / JEITA-enabled parts.
Edge device must support buffered upload for temporary disconnection.
SBS/SMBus command and alarm tables must be preserved inside TI / ST / NXP / Renesas / onsemi / Microchip / Melexis scope.
Test script hooks
Testers or automated rigs should run this sequence whenever a new pack model is introduced, even for small-batch shipments:
- SMBus address scan to detect actual pack address.
- Read identity (manufacturer, device, serial, firmware).
- Read charge control (ChargingCurrent, ChargingVoltage).
- Read alarm (BatteryStatus, AlarmWarning) and compare with current mapper profile.
- Inject a known fault and confirm the charger goes to limited / safe / read-only charging.
- Log to cloud/gateway with mapper profile ID so other devices can update.
This page does not publish raw register values and does not override BOM lists from other BMS pages.
Request a Quote
Validation / production test for SMBus battery comms
This chapter defines how engineers prove that the SMBus link between the charger domain and the smart battery pack is working, not only in the lab but also on the production line and in the field. It goes beyond “I can read a register” and requires verification of speed, completeness, error handling, drop-out behavior and cross-brand replacements.
Procurement note: In SMBus tables not yet validated, do not bulk-procure replacement packs.
Lab phase: multi-vendor capture
In the lab, test with real packs from the 7-brand scope (TI, ST, NXP, Renesas, onsemi, Microchip, Melexis). For each pack, run the following capture:
- SMBus address scan to detect the actual device address and confirm presence.
- Identity read: ManufacturerName, DeviceName, SerialNumber, FirmwareVersion.
- Mandatory charging-domain commands:
ChargingCurrent(0x14),ChargingVoltage(0x15),BatteryStatus(0x16), and at least one alarm-capable command. - Alarm table dump: record AlarmWarning / vendor-specific bits exactly as returned.
Differences between vendors must be written into the initial cloud telemetry mapper. Keep the raw dumps — production and field findings must be compared against these reference captures.
Production phase: fixed test script
On the line, use a fixed and repeatable script so operators do not have to know battery internals. A typical sequence is:
- Scan → discover SMBus address and confirm device presence.
- Read identity → compare with allowed vendor list (7-brand scope).
- Read mandatory commands → ChargingCurrent, ChargingVoltage, BatteryStatus, alarm-capable command.
- Read alarm/status → check against the mapper profile expected for this product.
- Simulate or inject a fault → confirm the charger enters limited / safe / read-only charge.
- Log to cloud / gateway → attach mapper profile ID and pack identity.
Production rule: If any charging-domain mandatory command fails, mark the pack as “mapper update required” and do not accept it as a good unit.
Field / service phase: periodic re-scan
Field devices and service tools must re-scan periodically because small-batch environments often insert a different or newer pack without notifying engineering. The device should:
- Re-scan SMBus on pack insertion / charge start / firmware update.
- Compare current AlarmWarning / status bits with the cloud-approved mapper.
- If unknown bits appear → go to limited charging + report.
This is what allows the system to detect “a replacement pack is outside the allowed 7-brand scope” even if the hardware stayed the same.
Cloud feedback & mapper update
All unknown alarm bits, changed command tables or unexpected SMBus addresses collected in the field must be fed back to the cloud telemetry mapper. The mapper publishes a new profile ID; production lines and field devices must pick it up before that replacement becomes a volume part.
This is the execution of the rule you repeated in other chapters: “Cloud-side telemetry mapping must be updated before using cross-brand alternatives.”
BOM / test wording (copy/paste)
In SMBus table not yet validated, do not bulk-procure replacement packs.
Packs failing any charging-domain mandatory SBS/SMBus command shall be quarantined for mapper update.
Field devices shall periodically re-scan SMBus to detect out-of-scope or new-firmware packs.
This chapter does not publish raw register values and does not override BOM lists from other BMS pages.
FAQ (SBS/SMBus charging domain)
The following questions are only for the charging domain of SBS/SMBus battery communications. They do not cover SoC/SoH algorithms, vehicle-level diagnostics, or USB-PD coordination. Answers are aligned with the BOM and mapper rules from previous chapters.
Frequently Asked Questions
Which SBS/SMBus commands are mandatory for a charger to read before starting CC/CV?
At minimum, the charger must read ChargingCurrent(0x14), ChargingVoltage(0x15), BatteryStatus(0x16), and at least one alarm-capable command. If any of these fail, the charger should not enter full CC/CV.
How do I normalize vendor-specific AlarmWarning bits when I mix TI and ST battery packs?
Use a cloud/gateway telemetry mapper. Each vendor’s AlarmWarning table is mapped to one charger-visible schema. Unknown bits force the charger into limited or read-only charging and must be reported back so the mapper can be updated.
Can I accept a pack that reports charging current but not the JEITA zone?
You can, but only in degraded / fixed charging mode. Add the BOM remark: “Devices that only support fixed-temperature charging must NOT replace NTC / JEITA-enabled parts.” This must also be logged so the mapper knows this pack lacks temperature data.
What is the safest way to update pack firmware over SMBus while the system is powered?
Follow the 6-step charging-safe flow: Identify → Authenticate/Unlock → Transfer profile → Verify → Relock → Notify cloud. Keep the charger in limited/safe charging during transfer and do not update unidentified packs.
How do I detect that a replacement pack is outside the allowed 7-brand scope?
Run the production script: address scan → identity → mandatory commands → alarm. If identity is unknown or any mandatory command fails, mark it as out-of-scope and trigger a mapper update request. Do not ship as an approved replacement.
What happens if the SMBus address or command table changes after procurement?
The device must report “unknown / changed SMBus structure” to the cloud. The cloud publishes a new telemetry mapper profile. Until the new profile is available, the charger should remain in limited/safe charging.
Can I downgrade to fixed-current / fixed-voltage charging if the pack does not expose alarms?
Yes, but only if the BOM clearly says so. This corresponds to the “A → B (degraded)” branch in the small-batch chapter. No OTA, no silent replacements, and the mapper must record that this pack does not expose alarms.
How do I log pack identity/serial to the cloud for later traceability?
At charge start, at pack replacement, or after an SMBus update, read ManufacturerName, DeviceName, SerialNumber and FirmwareVersion and send them to the cloud together with the mapper profile ID. That is how you can tell which batch had different alarms.
What BOM remark prevents purchasing from buying “SBS-like” packs with missing alarms?
Use this sentence unchanged: “SBS/SMBus command and alarm tables must be preserved when procuring cross-brand packs inside TI / ST / NXP / Renesas / onsemi / Microchip / Melexis scope.”
How do I map an AFE-based design (NXP / Renesas) to a charger that expects TI-style SBS?
Capture the forwarded AFE/MCU fields in the lab, create a mapper profile in the cloud that translates them into the TI-style schema, and make the charger read only the unified schema. Hardware does not change; the mapper does.
Can I lock the pack after verification so field devices cannot overwrite charge parameters?
Yes. After identity and alarm-table verification, issue the relock/write-protect command (often via ManufacturerAccess) so field devices cannot push wrong settings to another vendor’s pack.
How often should I re-scan and re-validate the SMBus command table in production?
On every supplier change, every new firmware from the same supplier, every out-of-scope pack detected in the field, and at least once per production batch. Any failure → mark as “mapper update required.”
