Logging
The BMS keeps two independent logs in its internal flash memory:
- Main log: one text record for each important event, such as entering the FAIL, ERROR or PROTECT state. A record is written to flash at the moment the event happens.
- Permanent log: snapshots of all permanent variables. A snapshot is written only on specific occasions: power loss, software reset, and periodically.
Both logs have a limited size. When a log is full, the oldest records are overwritten.
To share the logs with siliXcon, generate a diagnostic report in emGUI. The report contains both logs. See also how to show logs.
Main log
Print the main log with the log command, or show it in emGUI. Each record is also printed to the terminal at the moment it is written.
Example record:
DIAG_LOG(err 16, run 42, 3605 s): |2026-10-30 14:02:11 DISCH Current overload on DSC| [err| drv: 0, bal: 0] [62% 50.1200V 85.3000A, min: 3612mV 31C, max: 3640mV 32C]
The prefix before the colon:
| Field | Meaning |
|---|---|
DIAG_LOG | Firmware module that wrote the record |
err 16 | Severity of the record (critical) |
run 42 | Start counter: the run permanent, incremented at every start of the BMS |
3605 s | Seconds since the start of the BMS (the time permanent) |
The rest of the record (time stamp, state, event and the battery snapshot) is described in BMS log messages.
Every permanent log record contains the run and time permanents too, so they tie main log records and permanent log records together.
Logged events
| Event | Logged when |
|---|---|
FAIL/ERROR reason, e.g. Balancer error | The BMS enters the FAIL or ERROR state, and again whenever the reason changes. The text is the decoded reason, see FAIL/ERROR state. |
NONE | The ERROR state is cleared with the clr_err command (BMS3 only). |
Protect reason(s), e.g. Shortcut | A new protect condition appears, including cell undervoltage and overvoltage. Conditions that become active together are listed in one record, separated by commas. A condition that stays active is logged once; if it disappears and appears again, it is logged again. |
ER_LV | The BMS leaves the ERROR state (after clr_err). |
HT_ISL | The heatsink isolation voltage crosses its upper or lower limit. It is logged even when htsIsolCfg does not turn it into a FAIL. See hardware status. |
SMPS_S | BMS3 only. A short circuit of the built-in switched-mode power supply was detected. The BMS switches the ports off and goes to sleep. If the short is still present right after the BMS wakes up, it is not logged again. |
CMD | Manual record created with the driver_log command. Use it to mark a point in time, for example before a test. |
| Free text | Text written with log <text>. It is stored as typed, without the prefix and the battery snapshot. |
Other firmware modules can also write critical records, for example when the calibration cannot be reset to defaults.
Normal state changes (for example IDLE to DISCH), sleep and wake-up, and current limitation are not logged. The wake source history is shown by the wtf command.
The errorLog permanent gets a new entry only when the reason differs from its newest entry, while the main log gets a record on every entry into FAIL or ERROR. Repeated FAILs with the same reason show as several main log records, but as one errorLog entry. The number of FAIL entries is counted by the fail_counter permanent.
Permanent log
Print the permanent log with the pmlog command, or show it in emGUI. Each record is a snapshot of all permanents: energy counters, extremes, protectLog, errorLog, fail_counter, shortcut_counter and the others listed in permanent data.
While the BMS runs, the permanents live in RAM. They are written to flash only when a permanent log record is created. At every start, the BMS loads the permanents from the newest record.
When a record is created
| Occasion | Description |
|---|---|
| Power loss | The battery is disconnected from the BMS, or the BMS loses its supply in another way. The BMS detects the falling supply voltage and writes the record before it switches off. |
| Software reset | The firmware restarts the BMS: the reboot command, or a reset command sent over the bus (for example from SWTools or emGUI). |
| Periodically | After every 4 hours of awake operation. Time spent in sleep does not count, and the period starts again at every start of the BMS. |
When no record is created
- Watchdog reset, including the reset that follows a firmware crash.
- Reset pin.
- Power loss during a flash write, for example while parameters are being saved. The write in progress takes priority, and the BMS switches off without the record.
Sleep and wake-up do not restart the BMS. The permanents stay in RAM, so no record is needed and none is created.
The MCU reset reason printed by wtf shows which kind of reset happened last.
After a reset without a record, all permanents return to the values of the newest record. Everything that changed since that record is lost: the energy counters, the extremes, and also the newest errorLog and protectLog entries and the fail_counter and shortcut_counter increments. The main log is not affected, because its records are written immediately. If errorLog and the main log disagree, the main log is the reliable one.
If the main log shows the same run number twice, with the seconds since start going back, the BMS session in between ended without a permanent log record.
Protect and error history
protectLogis cleared at every start of the BMS. It, and the protect history printed bywtf, only covers the time since the last start. Earlier protect events are in the main log and in theprotectLogvalues of older permanent log records.errorLogis kept across starts. Entries added after the newest permanent log record are lost on a reset without a record.