Electronic – STM32 CAN bus Rx interrupt only triggers in loopback mode

All CAN hardware error checks are performed by hardware - the CAN controllers.

A CAN node cannot ack itself, by design. It will not receive its own messages. CAN is meant to have at least two nodes to work - a CAN bus with just one node is considered faulty, it is common sense. Therefore it doesn't make sense to have an "independent check".

(With one exception: if you enable a debug mode called "loop-back", which most CAN controllers support. Loop-back is a feature which allows the CAN controller to speak with itself without actually sending anything out on the bus. This is used for trouble-shooting and simulation purposes only and isn't meaningful to use in the final application. Typically you use this when you were cheap and only bought 1 evaluation board etc.)

The validation of message reception is done by the receiver acknowledging the message by setting the acknowledge bits in the CAN frame. http://www.can-cia.org/can-knowledge/can/can-data-link-layers/. This is done by the CAN controllers and nothing your software driver or application-level protocol need to concern themselves with, apart from checking the error flags after each transmission.

Now if you want to know if the right CAN node received the message, rather than any node, then that's another story not related to the hardware health of the bus. Such things have to be sorted in the high-level protocol.

One as transmitter and the other as receiver

It doesn't work that way. CAN is a peer to peer network. Any node can send a message at any time, and all the other nodes on the network receive the message.

constant 3,3V at the STM32 TX

This is clearly a firmware bug. The signal isn't getting to the CAN bus transceiver chip, let alone the CAN bus itself.

Things to be aware of:

1. The CAN lines need to be pulled together by about 60 Ω. That should be 120 Ω at each end of the bus. If the bus is really short, like a few inches on a single PC board, then a single 60 Ω resistor can be acceptable.

   On a real bus, this terminates the line to avoid reflections. However, this "termination" is still required even when the whole system is lumped. The resistance functions as a pull-together to keep the bus in the recessive state when not explicitly driven to the dominant state. This termination is not optional, even when it has nothing to do with terminating the transmission line.

2. You need at least two functioning nodes to have a working CAN bus. This is because the transmitter of a message expects to see the ACK bit asserted. With nothing but the transmitter on the bus, nothing will assert ACK, and the transmitter will think the message was corrupted and resend it. But see point 3.

3. The CAN standard attempts to prevent broken nodes from taking down the whole bus. If a node sees too many error conditions, it will shut itself down for a while. If you have only one node that never sees ACK, some of this error logic might get tripped after a while. I don't remember off the top of my head what conditions cause what level of disabling, but not having a full bus could cause the single node to disable itself, at least somewhat.