CAN reception issues: Reasons and general troubleshooting

[SofLit]

Introduction

CAN bus is a robust protocol to transmit/receive data. It can be very sensitive to any issue that could lead to communication errors or even halt communication. STM32 users need to have a basic knowledge of the CAN bus (protocol + hardware) to get started.

1. CAN communication issues

CAN communication issues can be caused by several different reasons:

1. Incorrect CAN configuration: Mismatched CAN/FDCAN configurations between nodes can lead to reception issues, including the correct baud rate (all nodes must have the same bitrate). Furthermore, incorrect timing settings, such as the CAN prescaler, TSEG1, and TSEG2 and incorrect sample point selection lead to communication issues. Incompatible bitrate versus bus length could also be an issue. CAN bitrate is limited by the bus length: The more you increase the CAN bitrate the more you need to decrease the bus length: 

   Image reference: https://www.researchgate.net/figure/CAN-transmission-speed-depending-on-the-bus-length-7_fig1_328227438  

2. Clock source selection: For CAN/CANFD communication, STMicroelectronics does not recommend the usage of the RC-based internal clock sources such as HSI/MSI/CSI etc. Mainly when normal mode is used (STM32 is connected on a CAN bus). These internal clock sources may impact communication performance as they could be influenced by different factors (temperature/voltage/reflow effects/ mechanical effects etc.). We recommended using HSE with an external crystal or another precise clock source in bypass mode.
3. Filter configuration: The CAN controller uses filters to determine which messages should be passed to the software. Incorrect filter configuration might result in the CAN controller discarding messages that should be received. Note that when there is no filter configured/activated you will not receive any message.
4. Physical layer issues: Problems with the physical layer, such as poor wiring, incorrect termination, or faulty transceivers, can cause reception issues. There could be a defect in the CAN controller hardware or other related components on the microcontroller. A genuine STM32 is needed to prevent unwanted behaviors.
   Incorrect GPIO configuration or incorrect GPIO selection prevents the frame to reach the CAN peripheral. A GPIO connected to something else other than the transceiver is an issue especially when an ST board is used. Tx/Rx pins need to be dedicated only to the transceiver (check the board schematics).
   Even if the CAN is a two-wires differential protocol, for more robustness, a common GND would be preferable due to some transceivers common-mode limitations. Some transceivers have a dedicated pin for standby/slope control. Generally, this pin needs to be tied to the GND at least to activate the transceiver. If the transceiver is in standby state, you cannot transmit or receive CAN frames. Refer to the specific transceiver documentation.
5. Bus overload: If there is too much traffic on the bus, it might lead to missed messages and errors.  A node could monopolize the bus, which causes network congestion. This overload can result in delayed message transmission or, in severe cases, loss of data.
6. Software bug: There could be a bug in your software, such as incorrect interrupt handling or buffer management or buffers that could be overwritten by another peripheral or task etc.
7. Electromagnetic interference (EMI/EMC): EMI can cause corruption of CAN frames, leading to errors and missed messages. CAN communication with high set bit rates are affected more by EMI than one with low set bit rates. Try to use a shielded and twisted pair cable (refer to this paper for more information). Moreover, to increase immunity against electromagnetic emissions and interferences, common-mode chokes (CMCs) are typically part of the CAN connecting circuits of a CAN node (See these links: Link 1 and Link 2).
8. Power issues: Incorrect power supplies and fluctuations can affect the operation of the CAN transceiver and the STM32. Some transceivers have two power supplies, one for its operation and one for the IOs to give a flexibility to the users to adapt their controllers IO's voltage to one of the transceivers. A power mismatch and incorrect power supplies on these power supply pins could lead to communication issues.
9. Device specific issues: Some issues might be specific to a particular microcontroller or platform being used. You need to check the relevant errata sheet in that case.
10. Driver (HAL) version: Using an outdated driver version might have unresolved bugs that affect CAN communication. Ensure that the latest firmware is being used.

2. General troubleshooting

To troubleshoot these issues, you can try the following:

• Verify the hardware connections and ensure proper termination of the CAN bus.
• Isolate the problem by simplifying the network or software to the minimum configuration that exhibits the issue.
• Check the filter configurations to ensure they are set up to allow receiving the expected messages.
• Review the CAN configuration settings for any discrepancies.
• Use an oscilloscope to check the form of the bits, the bit timing, the form of the frame and see if there is something abnormal.
• Use a CAN analyzer tool to monitor the bus, its load, and check for errors or unusual patterns.
• Look for any error flags or status indicators in the CAN controller registers.
• Update the firmware to the latest version if applicable.
• Simplify the code as much as possible. If you are using RTOS, other middleware's, other peripherals etc., remove them, and try to simplify the code as much as possible to relocate the issue. In many cases, CAN is not the issue but how you did integrate your application.

3. Best practice to get help from the ST Community

To maximize your chances for efficient help in the community, create a post in the adequate product forum. Provide more specific details about your setup, such as:

• Tag your thread with "CAN" or" "FDCAN" depending on the case.
• Precise symptoms of the reception issue.
• The hardware configuration (especially in normal mode): Schematics including the transceivers + terminating resistors + a sketch of how you did connect the CAN nodes on the bus.
• The code used, including the ioc file: Attach a minimal project that reproduces the behavior. Remove all other peripheral configurations that are not participating in the reproduction of the behavior.