English is currently available.
CAN & CANopen DISCUSSION
I am bringing up CAN on one board with a transceiver and a 120 Ω resistor, and no other node yet. When I send one frame, the scope shows the same frame repeated endlessly on the bus and the transmit-complete flag never sets. The controller's error status shows "error passive" after a moment.
Is this expected with only one node, or have I misconfigured something? And what is the difference between error active, error passive and bus-off?
This is expected. Every CAN frame contains an ACK slot: the transmitter sends it recessive, and any node that received the frame correctly overwrites it with a dominant bit. With no other node on the bus, nobody acknowledges, the transmitter detects an ACK error, signals it and retransmits. Automatic retransmission continues until somebody acknowledges, so you see the same frame forever.
Nothing is wrong with your code on that evidence. Add a second node set to the same bit rate (a USB-CAN adapter in normal mode, not listen-only) and the frame will be acknowledged and sent once.
The states come from two counters in every controller, the transmit error counter (TEC) and the receive error counter (REC). A transmit error adds 8 to TEC and a successful transmission subtracts 1. Below 128 the node is error active and signals errors with six dominant bits.
When either counter exceeds 127 the node becomes error passive: it can still communicate, but it signals errors with recessive bits that cannot disturb others, and it must wait an extra 8 bit times before starting another transmission of its own. When TEC exceeds 255 the node goes bus-off and stops driving the bus altogether until it is restarted, or recovers after seeing 128 occurrences of 11 consecutive recessive bits.
Your lone node stops at error passive rather than going bus-off, and that is by design. The rules contain an exception: once a transmitter is error passive, an ACK error that is not followed by a dominant bit during its passive error flag does not increase TEC any further. So TEC climbs by 8 per attempt to 128, which takes sixteen failed attempts, and stays there. A node that is merely alone is never forced off the bus.
If you do see bus-off, the cause is something else: a bit rate mismatch with other nodes, CANH and CANL swapped, a missing or faulty transceiver, or a short on the bus.
For testing with one board, use the controller's test modes. Loopback mode feeds transmitted frames back to the receiver internally and treats them as acknowledged, so you can check your bit timing values, filters and interrupt handling. Separately, a one-shot or "no automatic retransmission" option sends each frame once and reports the failure, which is useful for a node that may be alone at power-up.
On the scope, the endless frame is also a convenient way to measure the bit time: one bit at 500 kbit/s should be 2 µs wide.
In a finished product, handle these states in firmware instead of ignoring them. Monitor the error status, and on bus-off wait a while before re-initialising rather than restarting instantly in a loop; if the fault is a wiring short, immediate restarts just produce continuous error frames.
Put a timeout on transmit requests as well, so that application code is not stuck waiting for a mailbox that can never empty because the node is the only one powered.
