Log Error Catalog

Occasional CAN bus ACK/BIT/STUFF/FORM errors are normal electrical noise on the vehicle network, especially at power-up or with an accessory attached.

Harmless in small counts. Only investigate if a single ride logs thousands, which can indicate a loose connector or a failing node.

A cell reached the over-voltage protection threshold, usually at the very top of a charge or during regen on a full pack.

Occasional COV events near 100% are normal protection. Frequent COV faults on the same cell group suggest imbalance worth a balancing charge.

The spread between the highest and lowest cell exceeded the allowed limit — a cell-balance signal.

A wide spread at the top of charge is often transient. A persistent, growing spread across rides warrants a full balancing charge and monitoring.

The BMS could not reliably read one of its cell-monitoring boards (PL/AFE) — a communication problem between the pack controller and a cell group.

Sporadic retries can be normal. Sustained read failures on the same board can indicate a failing cell-board or harness and are worth a service check.

A cell-monitoring board reported a fault/alert register or CRC error over its internal bus.

Isolated events are usually transient noise. Recurring board faults point to a specific cell group and warrant inspection.

The BMS logged cell readings it flagged as invalid, often during initialization or a brief read glitch.

Generally benign self-diagnostics. Persistent floods can accompany a failing cell board.

The bike detected reduced electrical isolation between the high-voltage system and chassis. Can be triggered by moisture/condensation, especially after washing or in high humidity.

Often clears once the system dries out. A persistent isolation fault is a genuine HV safety concern — have it inspected before riding in wet conditions.

A battery module could not be brought online — a voltage mismatch, a module controller issue, or (on multi-pack bikes) a pack that is out of range to join.

On swappable/multi-pack setups this can be expected when packs differ in charge. Repeated failures to connect the same module warrant service.

The main contactor did not close because the precharge voltage did not match — the controller bus did not reach the pack voltage before closing.

Occasional events on startup can be benign. Persistent precharge failures can indicate a contactor or precharge-circuit problem.

The main board lost communication with an interface board within the timeout window.

Intermittent timeouts are usually transient. Repeated CIB disables can point to a wiring/connector issue.

The main board flagged an internal fault reported by a battery management system.

Note which BMS index is reporting and whether it recurs; recurring internal faults on one pack warrant service.

The BMS aborted or faulted the charge state machine — often a supply dropout, a handshake issue, or a protection trip during charging.

A one-off aborted charge is common with flaky supplies. Repeated charge faults on a known-good charger warrant investigation.

A charger reported low input/supply voltage — typically a weak wall circuit, a long extension lead, or a shared circuit under load.

Usually an external-supply issue, not a bike fault. Try a dedicated outlet.

The BMS shut the session down after repeated charge faults — a protective stop.

A genuine protective shutdown. Stop using that charger and have the charging path inspected if it repeats.

A voltage exceeded the critical protection threshold.

A genuine over-voltage protection event. If it recurs outside the very top of charge, have the pack inspected.

A controller firmware hard-fault/exception — the processor hit an unrecoverable state and reset.

Note the firmware version and whether it recurs. Persistent hard faults warrant a firmware update or service.

The ABS module reported an error — often a wheel-speed-sensor signal issue.

If the ABS warning light is on, have the wheel-speed sensors and ABS module checked; braking still works without ABS but the safety feature is degraded.

The board could not read the stored VIN and reset it to uninitialized — a cosmetic/firmware bookkeeping event.

Harmless to operation. If the VIN shows blank in the app, a dealer can re-write it.

The BMS could not initialize its internal error log at startup — internal housekeeping.

Benign self-diagnostic; no rider action needed.

An internal BMS I/O management call returned a non-success code — usually a transient internal retry.

Benign in isolation; only relevant if paired with sustained pack faults.

The firmware entered a protective shutdown after a critical error.

A genuine protective stop. Note what preceded it in the log and whether it recurs; a repeating critical shutdown warrants service.

The motor controller (Sevcon) hit a cutout fault and was restarted to clear it — often a transient torque/throttle or thermal protection trip.

An isolated cutout during hard acceleration can be normal protection. Frequent cutouts warrant a controller/throttle inspection.

The current sensor calibration was not set, so current readings may be less accurate until calibrated.

Benign for riding; a dealer tool can calibrate it if energy figures look off.

The BMS could not read stored statistics and reset them to defaults — internal housekeeping, occasionally after a firmware update.

Benign; some lifetime counters may reset. No rider action needed.

The BMS power-on quick self-test flagged a subsystem before going online — e.g. cell measurement ('Cells Failed') or the pack-I/O ADC ('PackIO ADC Failed').

An isolated self-test miss at boot can be transient. Repeated failures of the same subsystem point to a hardware issue on that pack and warrant service.

The BMS completed its self-test but raised one or more non-fatal warning flags (a bitfield) — noted diagnostics rather than a hard failure.

Benign if the bike operates normally. The flag value identifies which check was flagged for a technician if it recurs.

A BMS startup step failed and reported an error code; the controller typically retries the sequence.

Occasional startup retries that then succeed are usually benign. Persistent startup failures on one pack warrant service.

After a charge fault the BMS is retrying to resume charging — a normal recovery step, not a hard stop.

Benign if charging then continues. If it pairs with repeated charge faults on a known-good charger, see the charge state-machine family.

The onboard accelerometer (used for tip-over / lean sensing) failed its power-on self-test and is retrying.

Usually clears on retry and is harmless. A sensor that never passes can disable tip-over detection — worth a service check if it fails every boot.

The main board lost the loopback/heartbeat with a battery module — a communication dropout between the MBB and a module.

Isolated events are transient. Repeated loss on the same module points to a connector or harness issue on that pack.

The main board set a diagnostic trouble code because it hit a CAN communication error talking to a BMS.

Isolated events are transient noise. A persistent DTC from BMS CAN errors warrants checking the pack CAN wiring and connectors.

The onboard Bluetooth module (RN-42) did not exit command mode and was reset via its reset pin — a benign comms retry.

Harmless; affects only the phone Bluetooth link, not riding or charging.

Stored settings could not be read and were reset to defaults — internal housekeeping, sometimes after a firmware update.

Benign; some saved preferences may revert. No rider action needed.

The firmware extended the watchdog window so the bootloader has time to start — a normal part of the boot / firmware-update sequence.

Informational boot housekeeping; no rider action needed.

A controller's watchdog timer expired and reset the processor — the firmware stopped servicing the watchdog (a hang or an overrun); a stack trace is logged.

An isolated watchdog reset that recovers is often transient. Repeated WDT timeouts point to a firmware issue and warrant a firmware update or service.

The firmware's generic fault lifecycle — a named fault became active (set), was counting down (pending), or resolved (cleared). Severity depends on the named fault.

A cleared fault that does not return is resolved. Look at the specific fault name and whether it stays set.