Embedded firmware
CAN and FDCAN Bus Firmware Development
Kyros Engineering builds and repairs CAN and FDCAN firmware for multi-board industrial, agricultural and vehicle systems — protocol definition, message dispatch architecture, bus loading and arbitration analysis, and diagnosis of the intermittent bus faults that only appear with every node populated and the machine actually running.
Scope this with usA CAN bus rarely fails cleanly. It degrades: a node that misses one message in ten thousand, an arbitration loss that only happens when two subsystems talk at once, a bus that is fine on the bench and unreliable in the machine.
That class of problem is not solved by reading code. It is solved by instrumenting the bus, capturing the failure with timestamps, and correlating it against what each node believed it was doing.
Protocol design that survives the second board
Most CAN pain traces back to a protocol that was defined informally for two nodes and then grew. We define the message set as a versioned artifact before the code exists.
- Message IDs as named constants in one shared header, never magic numbers scattered across nodes
- Priority assignment reasoned against worst-case arbitration, not assigned in the order features were added
- An RX callback plus a dispatch table, rather than a polling loop that grows an if-chain
- Explicit behaviour for bus-off, error-passive and node-timeout states — decided, not defaulted
- Bus loading calculated at design time and re-measured on real hardware
FDCAN on STM32H7 is not bxCAN
This catches teams often enough to be worth naming. The H7 uses FDCAN with a shared message RAM that must have its filter banks and buffer regions configured before the peripheral is enabled. Code ported from an F4 bxCAN project will compile, initialise, and quietly fail to receive the messages you filtered for.
Diagnosing a bus that already exists
When you bring us a system that is misbehaving, we instrument before we theorise.
- Timestamped TX and RX logging at every node so the sequence is recoverable after the fault
- Physical layer checked first — termination, stub length, common-mode, and grounding between boards
- Error counters read and trended rather than sampled once
- Correlation of bus events against motor commutation, switching supplies and other in-machine noise sources
- A written root-cause finding, so the fix can be verified rather than believed
When to call
You probably want this if…
Frequently asked
Can you find an intermittent CAN fault we have chased for months?
That is the typical reason we get the call. The method is instrumentation, not inspection: timestamped logging at every node, physical-layer verification, and error-counter trending until the failure is reproducible on demand. A fault you can reproduce is a fault you can fix and then prove fixed.
Do you write the CAN protocol or work to ours?
Either. If you have one, we review it against worst-case arbitration and bus loading before we build to it. If you do not, we define it as a versioned artifact your team owns, with the message set in one shared header.
Is CAN still the right choice for a new design?
Often yes, for multi-board systems in electrically hostile environments where deterministic arbitration and mature diagnostics matter more than raw bandwidth. That is a system-architecture question, and it is exactly the kind we answer in an architecture diagnostic before hardware is committed.
Bus fault you cannot pin down?
Send us the symptom and the topology. We will tell you what we would instrument first.