Using CAN (bxCAN) in Normal mode with STM32 microcontrollers (Part 1)

mƎALLEm · ‎2025-06-25

Introduction
1. Typical CAN bus structure
2. bxCAN in Normal mode on STM32
2.1 Hardware considerations
2.2 Software considerations
2.2.1 Clock configuration
2.2.2 CAN I/Os configuration
2.2.3 CAN timing and parameter configuration
2.2.4 CAN filter configuration
2.2.5 Receive interrupts
2.2.6Integration of the solution in the final application
Conclusion
Related links

Introduction

CAN is one of the efficient protocols which was created by BOSCH in the early 80s. The purpose was to reduce the complexity and cost of electrical wiring in the automobiles. Then it was extended to the industrial and medical applications. The protocol was adopted by many semiconductors manufacturers to integrate it in their products. STMicroelectronics has integrated it on many of its microcontrollers, starting from the ST7 family of 8-bit microcontrollers, to the STM32 family of 32-bit microcontrollers.

On the STM32 there are two variants of the CAN protocol: bxCAN (CAN2.0) and FDCAN (CAN Flexible Data-Rate). This article covers the bxCAN variant which is available on many STM32 series like STM32F0xx, STM32F1xx, STM32F2xx, STM32F3xx, STM32F4xx, STM32F7xx etc.

This article is divided in two parts: part 1 (theorical) and part 2 (practical). This part (part 1) provides details on how to use bxCAN in Normal mode on STM32 with some software and hardware recommendations. Part 2 of the article provides an example implemented on many STM32 microcontrollers.

Note: This article is not intended to describe the CAN protocol nor how the CAN is working, but provides the necessary information to establish a CAN bus with STM32. So, you need a minimal knowledge of the CAN protocol to understand the content of this article.

1. Typical CAN bus structure

Figure 1 shows a typical CAN network topology where many CAN nodes are connected to the CAN network.

Figure 1. A typical CAN network topology

A CAN node is a CAN device intended to contain a CAN controller with a CAN transceiver. There is no leader-follower concept in the CAN protocol like SPI or I2C. Each CAN node connected to the CAN network is a leader and it is eligible to transmit and receive any frame on the bus with the respect to the CAN protocol. Each CAN node wins the arbitration phase continues to transmit its CAN frame. Others lose the arbitration and keep silent and listen to the bus till the end of the inter-frame space. A CAN node could be a controller, a sensor, an actuator, a CAN analyzer etc.

2. bxCAN in Normal mode on STM32

There are many modes supported by the bxCAN on STM32. Test modes (Silent mode, Loop back mode, Loop back combined with silent mode) and the Normal mode. The most used modes are the Loopback mode (see this article) and the Normal mode. The Normal mode is the mode where the CAN interface is intended to be used at the final application where many nodes (devices) will communicate together over a CAN network (shown in figure 1). Software and hardware considerations need to be taken in this mode for a normal CAN operation. Figure 2 shows a minimum CAN bus required using STM32.

Figure 2. A minimal CAN bus using STM32 microcontroller

2.1 Hardware considerations

With the Normal mode, a complete CAN bus needs to be established. A complete CAN bus means a wire pair (differential voltage to transmit data): CAN_H (CAN High) and CAN_L (CAN Low) terminated by two resistors of 120 ohm at both sides of the bus to prevent signal reflections. The CAN communication needs at least two CAN nodes that should be connected to that CAN bus. The two wires should be twisted (shielded or unshielded) in the final application.

Figure 2 shows the minimum hardware required to establish a complete CAN bus with STM32. The reason to have a minimum of two nodes on the bus is the fact that a CAN frame sent by a node needs to be acknowledged by at least a receiver (a second node), no matter if it was the intended recipient of that CAN frame. If only one node is available on the bus containing an STM32 and configured in Normal mode and transmits a CAN frame, it will not read a dominant bit in the acknowledgment slot supposed to be asserted by a second node (a receiver). Therefore, an acknowledgment error is generated. So, it is not possible to use a CAN interface with only one CAN node in Normal mode to probe CAN_Tx output. For that case, CAN Loopback mode needs to be used (read this article).

A CAN transceiver needs to be used in Normal mode. The transceiver needs to be selected carefully, especially its power supply and its I/O voltage levels. It is recommended to use a 3.3 V CAN transceiver or a 5 V transceiver with V_IO pin that adapts the voltage with STM32 I/Os. 5 volt transceivers without V_IO pin could be used. but you need to check the VIH min level of its Tx input pin.

Example of recommended transceivers:

SN65HVD230 is a 3.3V transceiver and it is already used on many of ST evaluation boards, like STM3210E-EVAL, STM3221G-EVAL, STM32373C-EVAL, STM3240G-EVAL etc.

Figure 3. SN65HVD230 pinout

SN65HVDA540 is a 5V transceiver but it has a V_IO pin for the voltage level shift.

Figure 4. SN65HVDA540 pinout with VIO pin (pin 5)

We can also use a CAN-FD transceiver for a CAN2.0 frame (see this FAQ). For that, another transceiver is recommended:

MCP2562FD which is a 5 V and CAN-FD transceiver that can reach up to 8 Mbps with a V_IO pin:

Figure 5. MCP2562FD pinout with VIO pin (pin 5)

Figure 6 shows a hardware example of CAN node content using an STM32 and SN65HVD230 CAN transceiver.

Figure 6. CAN node based on STM32 and SN65HVD230 CAN transceiver

Figure 7 shows a hardware example of CAN node content using STM32 and MCP2562FD CAN-FD transceiver. In this case two power supplies are needed: 5 V and 3.3 V.

Figure 7. CAN node based on STM32 and MCP2562FD CAN-FD transceiver

Some transceivers have a pin called standby (STBY) other has RS pin (mode select). We will not enter details for their usage but for normal operation we need to connect these pins to the GND. Refer to the corresponding transceiver datasheet.

It is quite recommended to use an external and accurate clock source for HSE for CAN communication to prevent any communication issues. HSI and similar internal clock sources are based on RC cell which could be influenced by different factors (temperature/voltage/reflow effects/mechanical effects etc.). The source could be a crystal, a crystal oscillator, or any external clock source up to 50 ppm should be acceptable. See figures 6 and 7.

Even if the CAN uses two-wires propagating differential signals (for noise immunity), for more robustness, a common GND would be preferable due to some transceivers common-mode limitations. So, it is preferable to connect all nodes grounds together as shown by figure 8.

Figure 8. CAN with a common GND

2.2 Software considerations

This section describes the consideration to be taken to configure the CAN peripheral in the application.

2.2.1 Clock configuration

As stated in the section 2.1 Hardware considerations, an external accurate clock source should be used for the CAN communication. For that, the system clock of STM32 should be fed from HSE either over the PLL or directly from the external source. This could be with HSE in Crystal configuration (OSC_IN/OSC_OUT STM32 pins are used) or HSE in Bypass mode (only OSC_IN is used).

Figure 9 shows the two valid paths of the system clock to use CAN in Normal mode on STM32F407 using STM32CubeMX. For both paths, HSE is used.

Figure 9. System clock source2.2.2 CAN I/Os configuration

Care must be taken when the user selects a GPIO pin for CAN_Tx and CAN_Rx pins. The chosen GPIO pins should be reserved for the CAN usage and there is no other external hardware or component connected to these pins except the CAN transceiver.

For the STM32F1 family, the CAN_Rx pin needs to be configured in "Input mode" while the CAN_Tx pin needs to be configured in "Alternate Function Push Pull".

Figure 10. CAN_TX and CAN_Rx pins configuration on STM32F10x

For other STM32 families featuring bxCAN, both CAN_Tx and CAN_Rx pins must be configured in Alternate Function Push Pull" even if the CAN_Rx pin is an input.

Figure 11. CAN_TX and CAN_Rx pins configuration except for STM32F10x

The I/O speed can be set to the "Medium". There is no need for "High" or "Very High" speeds.

There is no need for pull up/down resistors, it is recommended to avoid as several transceivers embed a pull-up resistor on their Tx pins internally.

Note: Check if the right and intended CAN pins are connected to the transceiver, as many users make a mistake when they connect the CAN pins to the CAN transceivers. Particularly, when they use an ST board and connect the wrong pins.

2.2.3 CAN timing and parameter configuration

The timing is something that needs to be considered carefully as any wrong or bad parameter could affect the CAN communication. It can lead to CAN errors, the transmission not starting, or nothing received by the CAN peripheral. The CAN timing and bitrate are described in detail in this article: CAN (bxCAN) bit time configuration on STM32 MCUs. So, it’s recommended to read that article before going ahead.

2.2.4 CAN filter configuration

The CAN filter must be configured to receive CAN messages. Even if all the CAN configurations are correct from hardware and software stand points, not activating the filter leads to never receiving any CAN message. When only CAN2 needs to be used, CAN1 RCC clock should be enabled. Otherwise, CAN2 is not going to function as it is considered as subordinate of CAN1 instance from an internal STM32 architecture standpoint and they share the same RAM and filters. Refer to this article: STM32 in dual CAN configuration: bxCAN Filter bank explanation and relation with CAN2 Start Bank parameter.

In this article, we do not go into details about the different filter configuration and their explanation. At least a filter should be enabled to receive a CAN frame or simply configure it to receive all the CAN frames with all parameters are set to 0 in ID Mask mode. By setting all mask parameters to zero, the filter is configured to accept all CAN frames, regardless of their identifier. This configuration is useful when you want to receive all CAN messages without distinction. The CAN filter should be assigned to one of the two available FIFOs: FIFO0 or FIFO1. FIFO0 and FIFO1 are buffer memories located inside the CAN peripheral in which received CAN frames are stored before being processed by the CPU.

To validate the CAN filter configuration, the Loopback mode can be used before establishing any CAN bus. After validating the CAN reception using the Loopback mode, you can implement the CAN filter configuration in the target application that uses the Normal mode.

Note that the CAN filters are not part of STM32CubeMX settings. They need to be added in one of the User Code sections in the project if it was generated by STM32CubeMX.

2.2.5 Receive interrupts

Polling mode could be used, but interrupts are recommended especially for frames reception. The NVIC IRQ line should be enabled for the FIFO for which the CAN filter has been assigned to: FIFO0 or FIFO1.

2.2.6 Integration of the solution in the final application

If you are planning to use an RTOS, consider starting with a basic application without RTOS and do the tests. If all are OK, move on with RTOS and make sure that the stack size of the task is sufficient for it.

Start to use low compiler optimization for debug purpose then you can optimize the code with the optimization intended to be set in the final application.

Conclusion

This article part 1 treated all the aspects of the CAN configuration in Normal mode from hardware and software stand points on STM32 microcontrollers.

The next part (part 2) provides a step-by-step configuration of how to create a project to communicate with CAN in Normal mode with a debug example.