Table of Contents
After passing the tedious theoretical part of the CAN journey, we finally cover the practical aspects of the CAN Interface. In this part of the tutorial, we will configure the STM32 CAN Peripheral and test it using a mode called loop-back.
First, we need to create a new project and open the.IOC file of the project. Within Connectivity, choose the CAN Interface. I am sure you can handle all these steps. Otherwise, I will highly recommend the STM32 Programming Course for beginners:
STM32 CAN Operating Modes
If you open the parameter setting, you notice that there are several operating modes of the CAN Interface: Normal, Restricted Operation, Bud Monitoring, External Loopback, and Internal Loopback.
Normal Mode, as its name suggests, is the standard communication mode, in which CAN can transmit and receive data.
In Restricted Operation mode, on the other hand, the MCU can only receive the remote frames. It has other peculiarities:
It can acknowledge valid frames.
It does not send data frames, remote frames, active error frames, or overload frames.
In case of error or overload conditions, it does not send dominant bits.
Instead, it waits for a bus-idle condition to resynchronize with CAN communication.
Restricted Operation Mode is automatically entered when the Tx handler cannot read data from the message RAM in time.
To leave this mode, the software must clear the ASM bit of the FDCAN_CCCR register.
This mode can be used in applications that adapt to different CAN bit rates. The application tests different bit rates. It leaves Restricted Operation Mode once a valid frame is received.
The Figure below explains the Bus Monitoring Mode clearly. This mode is useful in analyzing the bus without affecting it. Since Tx and Rx lines are connected internally, it can also be used to monitor its own frames without really transmitting them.
Finally, we have External and internal loop-back nodes, which we primarily use for testing. In external loop-back mode, the FDCAN treats its own transmitted messages as received messages and stores them (if they pass acceptance filtering) into Rx FIFOs. This mode is provided for hardware self-test. To be independent from external stimulation, the FDCAN ignores acknowledged errors (recessive bit sampled in the acknowledge slot of a data/remote frame) in loop-back mode.
Internal loop-back mode can be used for a “hot self-test”, meaning the FDCAN can be tested without affecting a running CAN system connected to the FDCAN_TX and FDCAN_RX pins. In this mode, the FDCAN_RX pin is disconnected from the FDCAN and FDCAN_TX pin is held recessive.
In this tutorial, we will use the Internal Loop-back Mode because we can test the CAN Interface without additional hardware.
STM32 CAN/FDCAN Bit Timings
The next on the to-do list is configuring the CAN Clock and bit timings. Let's look at the clock Configuration of the STM32G491 in my project. In your case, it could be slightly different. Pay attention to the PLLQ output, whose frequency value is 40 MHz.
If you scroll, you will find a field to choose the CAN Peripheral Clock Source. I chose PLLQ as the clock input.
Our next task is to define the prescaler to set the CAN operating frequency. Please pay attention to the fact that we have a Nominal Prescaler and a Data Prescaler. As mentioned before, the STM32 FD CAN allows increasing the bit rate during the data transaction. The Nominal Prescaler dictates the frequency during the arbitration phase, while the Data Prescaler dictates the frequency during the data phase. In our case, I set both values to 32 to have 1.25 MHz in both cases. We call the reverse of this frequency a **time quanta (Tq)**, which you might encounter in other technical documents.
So, the equations are:
The CAN Interface has no clock to synchronize the data segments. Hence, perfect timing is crucial for the proper operation of the bus. For that reason, the bit time is divided into different regions to adjust the sampling point of the data: Synchronization segment, Bit segment 1, and Bit segment 2. The synchronization segment points to the start of the bit time, and its duration is always a single time quanta (a single time quanta). Bit segment 1 (BS1, Phase segment 1 in STM32 CAN) defines the location of the sample point, while Bit segment 2 (BS2, Phase segment 2 in STM32 CAN) defines the location of the transmit point.
Do not be afraid of these technical words, because there are simple rules we can follow to configure their values. The sum of the data segments constitutes the duration of the data bit:
In other words, the baud rate equals:
Another rule of thumb is that the sample point (BS1 + 1) must be 80-90% of the bit time, which means BS1 is quite long compared to BS2. This is to ensure that sampling occurs after the data level has completely settled.
Another essential feature of the STM32 CAN is that nodes can adjust the bit timing dynamically to prevent data errors. The nodes' frequency values can vary slightly from one another, and the lengthening or shortening of the bit time is crucial to ensure the correct operation of the bus. The synchronization jump width (SJW) defines an upper bound for the amount of lengthening or shortening of the bit segments. It is programmable between one and four time quanta. The reference manual says:
"A valid edge is defined as the first transition in a bit time from dominant to recessive bus level, provided the controller itself does not send a recessive bit. If a valid edge is detected in BS1 instead of SYNC_SEG, BS1 is extended by up to SJW, thereby delaying the sample point. Conversely, if a valid edge is detected in BS2 instead of SYNC_SEG, BS2 is shortened by up to SJW, so that the transmit point is moved earlier."
Finally, I configured the bit timing parameters as shown in the figure below. The input clock frequency is 40 MHz, and the baud rate is 50 kbps for both the arbitration and data phases.
Finally, we need to enable the interrupt within NVIC settings
