Introduction
The CAN-FD protocol implements a robust error management mechanism, which is fully implemented in hardware. It is reported mainly by two counters in the same way as CAN2.0 (bxCAN in STM32):
- Transmit error counter (TEC)
- Receive error counter (REC)
Both counters reside within the FDCAN_ECR register (error counter register) and dynamically increment or decrement based on the error conditions detected during the communication. Monitoring these counters allows software to assess the health and stability of the CAN network. Complementing this, the FDCAN_PSR register provides detailed error status information, enabling precise diagnostics. Furthermore, the FDCAN_IE register allows configuration of interrupt generation for error events, facilitating timely and flexible error response mechanisms.
In this article: the wording “FDCAN” refers to the peripheral incorporated in STM32 MCUs while “CAN-FD” refers to the protocol.
- Introduction
- 1. Understanding the Bus-Off state in STM32 FDCAN
- 2. FDCAN recovery method from Bus-Off state
- 3. FDCAN Bus-Off recovery using HAL
- 4. Bus-Off fault injection and recovery demonstration projects
- Conclusion
- Related links
1. Understanding the Bus-Off state in STM32 FDCAN
The Bus-Off state is a protective mode that the FDCAN controller enters when the transmit error counter (TEC) surpasses the threshold of 255, as depicted in Figure 1. This condition typically results from sustained transmission errors on the CAN bus, indicating significant communication issues.
While in the Bus-Off state, the FDCAN module is effectively disconnected from the bus. It cannot transmit or receive any messages. This safeguard prevents further disruption of the network caused by a faulty node. It is important to highlight that the Bus-Off condition is triggered by a transmitter not by a receiver, disturbing the communication. A receiver-only node (listen mode) does not enter this state.
Recovering from the Bus-Off state requires a specific sequence to ensure that the node safely rejoins the network without causing additional errors. Understanding and properly handling the recovery process is essential for reliable CAN-FD communication.
Figure 1. FDCAN error state diagram
The BO bit (bit 7) indicates the Bus-Off state in the FDCAN protocol status register (FDCAN_PSR). When the Bus-Off state occurs, the BO bit is set.
2. FDCAN recovery method from Bus-Off state
The Bus-Off recovery is the process by which a node on a CAN bus returns to an operational state. It is then able to retransmit CAN frames after its own transmit error counter exceeds the critical threshold TEC > 255. To recover from the Bus-Off state, the FDCAN node must wait through a recovery sequence defined by the FDCAN specification. This sequence involves monitoring 129 occurrences of 11 consecutive recessive bits on the FDCAN_RX input. This monitoring is transparent to the user level, and it is performed at the hardware level. Contrarily to bxCAN, which needs to monitor 128 occurrences of 11 consecutive recessive bits.
The FDCAN peripheral requires software intervention for Bus-Off recovery. This is because the FDCAN interface does not support hardware automatic recovery. Which is not the case with some STM32 series, such as STM32F1, STM32F4, and STM32F7, that feature the bxCAN version with automatic Bus-Off recovery managed by hardware, through the ABOM bit in the CAN_MCR register.
According to the FDCAN specification described in the reference manual, two conditions must be met for the node to recover from the Bus-Off state:
- The INIT bit in the FDCAN_CCCR register must be cleared by software after a Bus-Off occurrence.
- At hardware level, the node must detect 129 occurrences of 11 consecutive recessive bits on the FDCAN_RX input.
After that, the node can start to transmit on the CAN bus.
3. FDCAN Bus-Off recovery using HAL
To implement Bus-Off recovery:
- Enable the FDCAN NVIC interrupt line, either manually or using the STM32CubeMX interface.
- Activate the Bus-Off notification interrupt with the following code:
HAL_FDCAN_ActivateNotification(&hfdcan1, FDCAN_IT_BUS_OFF, 0); - implement the error status callback to handle the Bus-Off event:
void HAL_FDCAN_ErrorStatusCallback(FDCAN_HandleTypeDef *hfdcan, uint32_t ErrorStatusITs) { FDCAN_ProtocolStatusTypeDef protocol_status; HAL_FDCAN_GetProtocolStatus(hfdcan, &protocol_status); if (protocol_status.BusOff != 0) // If Bus-Off error occurred { CLEAR_BIT(hfdcan->Instance->CCCR, FDCAN_CCCR_INIT); // Clear INIT bit to recover from Bus-Off } } Alternatively, you can do it simply this way:
void HAL_FDCAN_ErrorStatusCallback(FDCAN_HandleTypeDef *hfdcan, uint32_t ErrorStatusITs) { if ((ErrorStatusITs & FDCAN_IT_BUS_OFF) != 0) // If Bus-Off error occurred { hfdcan->Instance->CCCR &= ~FDCAN_CCCR_INIT; // Clear INIT bit to recover from Bus-Off } }
4. Bus-Off fault injection and recovery demonstration projects
In the article, two projects are attached where NUCLEO-H563 is used as an FDCAN node configured to communicate in classic frame format. Another STM32 having bxCAN interface that represents the second node that needs to be connected to the bus for the test. The second node is a NUCLEO-F767 Nucleo board.
Here is how to test the Bus-Off and the recovery using the two projects:.
- Compile both projects and upload firmwares to the correspondent boards.
- Connect two nodes via the CAN bus CAN_H/CAN_L lines over CAN transceivers from both sides.
- Start communication (using debug mode) between the nodes and ensure that the CAN frames are transmitted/received well by both nodes by showing the Rx messages from each node.
- Short-circuit the CAN_H and CAN_L lines.
- The CAN transmitter NUCLEO-H563 enters the Bus-Off state. NUCLEO-F767 also enters the Bus-Off state.
- The HAL_FDCAN_ErrorStatusCallback() is called. You can put a break point in it.
- While the CAN_H and CAN_L lines remain shorted, the node NUCLEO-H563 stays in Bus-Off and the HAL_FDCAN_ErrorStatusCallback() still triggering.
- Once the short circuit is removed, the node NUCLEO-H563 monitors 129 consecutive recessive bits before resuming the CAN transmission. NUCLEO-F767 recovers automatically by hardware as the automatic Bus-Off recovery by hardware is enabled.
Conclusion
This article explained the Bus-Off state behavior and management of the FDCAN peripheral in STM32. It also highlighted the limitation that automatic hardware recovery is not supported in FDCAN, unlike in some other STM32 CAN peripherals featuring the bxCAN version. It also provided a software-based method to recover from the Bus-Off state, following the recommendations outlined in the product user manual. Proper handling of Bus-Off recovery ensures reliable CAN communication and robust error management in your STM32-based applications.
