Making Battery Charging Safe Before Firmware Loads

Hardware charge-current limiting, thermal cutoff paths, charger fault latching, and safe charging defaults before MCU control

Battery charging should not wait for the firmware to become responsible.

That is one of the most important rules in product hardware.

A device may be plugged in while the MCU is still held in reset. The bootloader may not have started. The firmware image may be corrupted. The processor may be asleep. The system may be recovering from brownout. The charger may see an adapter before the rest of the board has decided what mode it is in.

During that window, the battery and charger circuitry are already electrically alive.

If the design assumes firmware will quickly configure charging limits, monitor temperature, control enables, or respond to faults, the product has already accepted unnecessary risk.

At Hoomanely, we treat battery charging as a hardware-owned safety path first and a firmware-managed feature second. Firmware can improve charging behaviour, adjust profiles, report state, and optimise user experience. But it should not be required for the first layer of safety.

The hardware must know what to do before software exists.

That means safe charge-current defaults, thermal cutoff paths, charger fault latching, adapter tolerance, and clear ownership of what happens when the MCU is absent, late, or wrong.

A product is not safe because firmware usually boots.

It is safe because the hardware remains disciplined when firmware does not.

Charging Starts Before the Application Starts

In many systems, plugging in power begins the charging decision before the main application is ready.

The adapter voltage arrives.
The charger IC wakes.
The battery path becomes active.
The system rail may begin to rise.
The MCU may still be waiting for reset release.
Firmware may not yet know that charging has begun.

This is normal.

The problem appears when the design behaves as if firmware is already in charge.

For example, if the charger defaults to a higher current than the thermal design can tolerate, the board can heat before the MCU has a chance to reduce it. If the battery temperature path depends on ADC sampling, there is no thermal protection until firmware runs. If charger enable depends on an uninitialized GPIO, the charging state may be undefined during boot. If a fault is only logged in software, the reason may disappear after reset.

A safe architecture assumes the charger may act independently at the beginning.

The default state must therefore be safe even with the MCU unpowered, held in reset, blank, crashed, or asleep.

This does not mean charging must be disabled by default in every product. It means the default charging state must be intentionally chosen and electrically bounded.

Charge Current Should Have a Hardware Ceiling

Firmware-controlled charge current is useful.

It allows different adapter modes, thermal derating, user modes, battery health optimization, and region-specific behavior. But firmware control should sit below a hardware ceiling.

The board should include a maximum charge-current limit that cannot be exceeded because firmware made a mistake or failed to start.

This ceiling may come from the charger IC configuration resistor, input current limit resistor, ILIM pin, USB power negotiation limits, NTC network behavior, or a dedicated current-limit switch in the input path. The exact method depends on the charger topology, but the principle is the same:

The hardware must define the worst allowed charging current.

That current should be selected from the real product limits, not the battery datasheet alone.

A cell may support a certain charge rate, but the product may not. The enclosure may trap heat. The PCB copper may be limited. The adapter may sag. The connector may have resistance. The battery cable may be thin. Nearby sensors may drift with heat. A plastic area may become uncomfortable. A regulator may share the same input path.

Charging current is not only a battery parameter.

It is a system thermal and power-integrity decision.

At Hoomanely, we choose the default hardware current limit as the value the product can survive safely without firmware intervention. Firmware may later request a better mode, but the hardware ceiling remains the guardrail.

Safe Defaults Matter More Than Smart Profiles

A smart charging profile is valuable only after the system is alive.

Before that, defaults matter more.

The charger enable pin, charge-current setting, input current limit, termination behavior, thermal input, battery supplement mode, power-path behavior, and fault output should all have known states at power insertion.

Unconnected or floating control pins are not acceptable in charging paths. A floating enable can turn charging on in one unit and off in another. A floating current-select pin can choose the wrong range. A weak pull on a thermal input can create a false normal-temperature condition. A charger mode pin can sample incorrectly during rail ramp.

A good hardware design answers these questions without firmware:

Is charging enabled or disabled at plug-in?
What is the maximum current?
What happens if the MCU pin is high impedance?
What happens if the battery thermistor is disconnected?
What happens if the adapter is weak?
What happens if the charger reports a fault before boot completes?

The safe answer should be built into the resistor network, pull strategy, charger configuration, and power-path logic.

The design should not depend on the MCU racing to configure safety after power appears.

Thermal Cutoff Must Have an Analog Path

Battery temperature is too important to depend only on firmware.

Firmware can read temperature through an ADC and make good decisions. It can derate charge current, pause charging, log thermal trends, and report warnings. But the first thermal protection layer should be analog or charger-native.

Most charger ICs provide an NTC or TS pin for battery temperature qualification. That pin should be used intentionally. The resistor network should represent the allowed charging temperature range. If the thermistor is missing, shorted, open, or out of range, the charger should enter a safe state.

This path must work before firmware loads.

It should not require the MCU to sample an ADC, calculate a temperature, and then disable charging.

The analog thermal path is the charger’s first sense of whether charging is allowed.

For product architecture, the thermal path should include more than a copied reference circuit. It should consider thermistor placement, battery pack wiring, connector failure, tolerance stack-up, self-heating, board heat sources, and worst-case enclosure temperature.

A thermistor placed far from the cell may protect the PCB but not the battery. A thermistor connected through a noisy or fragile cable may report unstable values. A charger TS pin tied into a firmware-controlled network may behave unpredictably during boot.

The thermal cutoff path should be physically close to the risk and electrically independent enough to act when the system is not yet intelligent.

Charger Faults Should Not Disappear During Reset

Faults during charging are often short-lived.

Input overvoltage.
Battery absent.
Thermal fault.
Safety timer fault.
Charge timeout.
NTC fault.
Input current collapse.
Charger thermal regulation.

If these occur before firmware starts, or while the MCU resets, they can disappear before anyone records them.

That creates a painful debug problem. The product may behave oddly, stop charging, reboot, or show reduced runtime, but there is no evidence left.

A charger fault output should therefore be treated as a diagnostic signal, not just a status pin.

For important faults, latching is useful. This can be done through a charger with persistent fault status, a small latch circuit, a supervisor, a retained logic domain, or firmware reading a charger register early before clearing it. The architecture depends on the system, but the intent is the same:

Do not let safety events vanish silently.

At Hoomanely, we like fault paths that survive long enough to be observed. A latched fault can drive a status indicator, block re-enable until reviewed, or preserve context for firmware after boot. It can also help factory teams separate charger faults from battery faults, adapter faults, connector faults, and firmware faults.

A safe product does not only stop unsafe charging.

It explains why charging stopped.

The MCU Should Request Charging, Not Guarantee Safety

The MCU can manage charging policy, but it should not be the only thing preventing unsafe charging.

This changes the control philosophy.

Instead of the MCU being the safety authority, the MCU becomes a requester. It may request charge enable, request higher current, request a thermal derating mode, or request ship-mode exit. But the hardware decides whether that request is allowed.

That means charger enable may be gated by multiple conditions:

• adapter valid,
• battery present,
• temperature valid,
• hardware current limit set,
• charger fault absent,
• system rail stable,
• and MCU request valid.

If any critical hardware condition is false, charging does not proceed just because firmware asked for it.

This approach protects against firmware bugs, corrupted GPIO states, brownout behavior, or unexpected resets during charging.

It also improves certification and safety review because the safety-critical behavior is visible in hardware, not hidden entirely in code.

The product becomes easier to reason about.

The MCU can optimize.

The hardware protects.

Input Power Negotiation Needs a Safe Pre-Negotiation State

Modern products often receive power from USB-C, adapters, docks, or shared power sources.

Before negotiation completes, the available current may be limited. The charger must not assume the highest possible input capability.

If the charger pulls too much current before input validation, the adapter may collapse, the system rail may brown out, or the product may enter a repeated attach-detach loop.

Safe charging design therefore needs a pre-negotiation current limit.

At plug-in, the hardware should start from a conservative input current state. Only after the power source is confirmed should the system allow higher current. If USB PD or other negotiation is involved, the charger should not jump to high charge current before the negotiated profile is valid.

This is another case where perceived intelligence should not precede electrical truth.

Before the system knows the input source, it should behave politely.

That protects the adapter, the connector, the charger, the battery, and the rest of the board.

Charging Heat Affects the Whole Product

Charging is not thermally isolated.

Heat from the charger, battery, input protection, power-path FETs, and nearby regulators can affect sensors, clocks, RF behavior, enclosure temperature, and user perception.

A charging design that is electrically safe but thermally disruptive can still damage product quality.

For example, a sensor board may drift during charging. A nearby oscillator may experience thermal shift. A plastic enclosure may warm unevenly. A temperature sensor may measure board heat instead of environmental condition. A battery NTC may lag behind actual cell heating if the pack is placed poorly.

This is why charging current should not be chosen only from maximum allowable ratings.

The product should define charging modes that respect the rest of the system:

safe default mode before firmware, normal mode after validation, derated mode during high product activity, and fault mode when thermal margin is low.

The charging path is part of the system thermal architecture.

It cannot be treated as an isolated power feature.

Safe Charging Must Survive Assembly and Service Conditions

Battery and charger circuits experience real-world handling.

The battery connector may be inserted late. The thermistor line may be open during assembly. The adapter may be plugged in without the battery installed. The board may be tested from a bench supply. A service technician may replace a pack. A partially seated connector may connect power before sense lines.

A product-grade charger design should handle these conditions safely.

The design should define what happens when:

• battery is absent,
• battery sense is missing,
• NTC is open or shorted,
• adapter appears before battery,
• battery appears before adapter,
• system rail is externally powered,
• charger fault occurs during factory test,
• or the MCU is not programmed yet.

These are not rare edge cases in manufacturing. They happen naturally during bring-up, assembly, rework, and field service.

A charger that is safe only after final assembly is not safe enough.

Hoomanely’s View: Charging Is a Hardware Safety Contract

At Hoomanely, we see charging as a contract between the input source, charger, battery, thermal design, firmware, and user experience.

The input source promises only what it can provide.
The charger must not demand more before negotiation.
The battery must not be charged outside safe temperature and current limits.
The thermal design must absorb the heat without disturbing the product.
Firmware may improve behavior, but hardware must define the safe envelope.
The user should never depend on software booting successfully for the product to remain safe.

This is why we design the charging path with default safety first.

Pulls are intentional. Current limits are bounded. Thermal cutoff is analog. Faults are visible. Charging requests are gated. Higher-current modes are earned only after the system knows it is allowed.

That is not overdesign.

That is respecting the fact that charging begins before the product is fully awake.

Final Thoughts

Battery charging safety cannot begin after firmware loads.

The charger may already be active while the MCU is reset, unprogrammed, crashed, or waiting for power negotiation. The battery and input source do not wait for the application to become smart.

A safe design starts with hardware-owned limits.

Charge current has a ceiling. Thermal cutoff has an analog path. Faults can latch or remain observable. Enable pins have defined defaults. Input current begins conservatively. Firmware requests charging; it does not guarantee safety alone.

That is the Hoomanely hardware design perspective.

Let firmware make charging better.

But make hardware keep charging safe.