Finite-State Machine (FSM)

Overview

The FSM governs board modes and transitions: initialization, ready, torque active, regen active, programming, bootloader, and fault. It centralizes state logic and actions.

File locations

• Generic driver: Drivers/common/drivers/fsm
• Board-specific state machine: Core/Src/App/Tasks/task_board_fsm.c and Core/Inc/App/Tasks/task_board_fsm.h

States and transitions

Typical states:

• INIT: Run self-tests, initialize peripherals, configure drivers.
• READY: Normal idle state; accepts control commands.
• TORQUE_ACTIVE: Actuation enabled; accepts torque commands and supervises limits.
• REGEN_ACTIVE: Regeneration active; similar to torque but inverted power flow.
• PROGRAMMING: Firmware programming state; restricts normal operation.
• BOOTLOADER: Bootloader chainloading state.
• FAULT: Terminal or recoverable fault state; awaits reset or safe recovery.

Transition examples:

1. INIT -> READY: After all self-tests pass and sensors report valid ranges.
2. READY -> TORQUE_ACTIVE: When a valid torque enable command is received and pre-checks pass.
3. TORQUE_ACTIVE -> FAULT: On overcurrent, overtemp, or other safety breach.
4. ANY -> PROGRAMMING: On entering programming mode via authenticated command or hardware pin.

Event handling and actions

• Events are queued by drivers and polled by the FSM task.
• Entry actions: configure outputs, enable timers, send status frames.
• Exit actions: disable actuators, persist minimal state if required.

Design notes

• Keep state handlers small and pure: calculate next state from current state + event.
• Prefer explicit transitions over implicit side-effects.
• Log every transition for offline analysis.

Testing and verification

• Add scenario tests that simulate sequences of events and validate state trace.
• Use CAN telemetry to assert correct broadcasted mode changes.