CAN and CAN FD

Electrical interface, bus timing, available Rust targets, and the exact boundary between tested CAN support and the planned ranging application protocol.

ControllerSTM32 FDCAN2

TransceiverTCAN1044VDRQ1

Logic pinsPB12 RX / PB13 TX

Range-over-CAN is not released yet.

The physical layer and standalone classical CAN / CAN FD test programs are present. The production ranging roles currently publish distance over USB CDC only; no stable CAN identifier or range payload contract has been assigned.

Electrical interface

J2 pin	Signal	Connection
`1`	`CAN_L`	Twisted-pair low
`2`	`CAN_H`	Twisted-pair high
`3`	`+12V`	Board power
`4`	`GND`	Power return and bus reference

The interface is non-isolated. SW3 closes a 120 Ω termination path through R20. Terminate only the two physical ends of a linear bus, keep stubs short, and use a twisted pair for CANH/CANL.

Tested firmware profiles

Targets	Nominal	Data	Payload
`can_tx` / `can_rx`	500 kbit/s	n/a	4-byte request, echoed response
`can_fd_tx` / `can_fd_rx`	1 Mbit/s	2 Mbit/s with BRS	64-byte load frame

These values describe repository test firmware, not the maximum rating of the transceiver. The TCAN1044 family supports faster signaling, but the complete bus topology and every node's bit timing must be validated before increasing the data phase.

Classical CAN echo contract

CAN ID	Direction	DLC	Bytes
`0x123`	TX node → RX node	4	`CA FE seq 00`
`0x456`	RX node → TX node	4	Echo of received request

This is a hardware-in-the-loop diagnostic contract only. IDs may change and are not reserved for the future range protocol.

CAN FD load frame

Offset	Type	Meaning
`0..3`	`u32 LE`	Wrapping sequence number
`4..7`	`u32 LE`	Sender `embassy_time` tick count
`8..63`	bytes	`0xAA` fill

The frame uses standard ID 0x100, 64-byte DLC, FD format, and bit-rate switching. The receiver reports sequence gaps and aggregate payload throughput. Its “one-way latency” is meaningful only when both boards share a synchronized tick epoch; otherwise treat that field as a diagnostic, not a calibrated latency measurement.

Two-board bring-up

Power both tags and connect J2 pin 1 to pin 1, pin 2 to pin 2, and pin 4 to pin 4.
Enable SW3 termination only at the two physical bus ends. With two tags as the complete bus, enable both.
Flash can_tx to one board and can_rx to the other over SWD.
Confirm the TX log receives ID 0x456 echoes with matching sequence bytes.
Repeat with can_fd_tx and can_fd_rx, then inspect sequence gaps and throughput.

cd firmware/rust_bringup/stm32g4
DEFMT_LOG=info cargo run --release --bin can_rx
# In a second checkout / terminal with the other probe:
DEFMT_LOG=info cargo run --release --bin can_tx

Fault isolation

Symptom	Check first
No frames, no bus activity	Common ground, CANH/CANL polarity, SWD image, transceiver supply
TX retries or no acknowledgement	A second active CAN node at the same nominal bit rate
Works at 500 kbit/s, fails in FD	Data-phase timing, BRS support, topology, cable length, termination
High sequence loss	RTT logging overhead, receiver servicing, wiring reflections, error counters

Complete Rust source

can_tx.rs500 kbit/s request and acknowledgement node.can_rx.rs500 kbit/s receive and echo node.can_fd_tx.rs64-byte CAN FD load generator.can_fd_rx.rsCAN FD loss and throughput receiver.

← USB serial Rust examples →