Electronic – Problem with CAN on STM32

canstm32

I want to let two STM32 communicate via CAN bus. One as transmitter and the other as receiver. In order to do that, I combined each with a MCP2551 transceiver. As long as the CAN operating Mode was set to LOOPBACK everything seemed to be good: The controller were able to send CAN messages, receive them(their own), and send it via UART to my PC (worked well). As next step I wanted to let them communicate with eachother. I set the operating mode of them to NORMAL. While the transmitter was sending the same messages as in Loopback Mode, and the Receiver was sending nothing (just waiting for any messages to come in), nothing happened. A measurement showed constant 2,5V at the transceivers output (Recessive State), and constant 3,3V at the STM32 TX (PA12). Anyone an idea what I'm doing wrong?

Best Answer

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.

Related Topic