Introduction
As many know, CAN test mode is used for debug or test. One of the test modes is the CAN Loop Back mode which is mainly used when only one CAN node is available, and the user needs to test the CAN functionality with no need to establish a CAN bus. Establishing a CAN bus means the usage of CAN in Normal mode that needs at least two CAN nodes to establish a CAN connection. One of the most usage of CAN Loop Back mode is the bitrate check on Tx and the filter configuration validation on Rx.
1. bxCAN Loop Back mode
This mode is a configuration where transmitted CAN messages are looped back to the Rx input. The bxCAN peripheral performs this when the LBKM bit is set in the CAN_BTR register. This allows a connection for the Tx output to Rx input internally to the peripheral. Therefore, all transmitted messages are received in the CAN reception FIFO. In Loop Back mode, the user can monitor the transmitted messages on Tx pin. In this mode, a CAN transceiver is not mandatory as the signals are looped back internally in the CAN peripheral.
Meanwhile, users can face issues either on transmit or receive in this mode. In the next two sections, we provide the most probable issues you may face either on transmitting or receiving CAN frames in Loop Back mode.
2. Troubleshooting CAN on transmission
While the user needs to probe CAN frames on CAN_Tx pin using an oscilloscope or logic analyzer, they can face an issue on showing CAN frames. The most probable reasons for this are:
2.1. Wrong GPIO configuration
It could be either a GPIO not set to the correct mode, that is, in GPIO alternate function push-pull mode (GPIO_MODE_AF_PP) or the GPIO alternate function is not correctly configured. In that case the user needs to check the alternate function mapping table provided in the product datasheet.
STM32F7xx as example:
If the user selects PB9 GPIO for CAN1_Tx, they need to select AF9 as an alternate function.
In the software, the CAN1_Tx pin configuration needs to be:
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Alternate = GPIO_A9_CAN1;
Note that if the code is generated with STM32CubeMX, the GPIO setting issue is not the reason, as the tool configures the alternate function correctly unless there is a limitation. In that case, raise the issue in the ST Community product forums.
2.2. Wrong probed Tx GPIO
The user can either set a specific GPIO for CAN_Tx but they probe another GPIO due to confusing schematics or cluttered hardware. Additionally, by using connectors with a high number of pins which lead to wiring issues. In that case, the user needs to check carefully the wiring and connections. Check schematics, mostly if there are some solder bridges are in the path of the connection. If no additional solutions are available, use the continuity option of a multimeter to confirm the correct pin. Alternatively, simply toggle the GPIO pin in question and check it with the oscilloscope.
2.3. Tx pin is connected externally to something else or broken I/O
Sometimes the user is sure about the connection and the correct Tx pin and its configuration, but the pin keeps the same voltage level. At this stage, the doubts may go to something forcing externally the voltage level of the I/O. In that case, the user needs to check the board schematics and verify if there is another circuit, or another source connected to that pin.
Check the solder bridges as they can connect the output to something else on the hardware. If the schematics are confusing, try to use the continuity option in the multimeter. Alternatively, simply toggle the GPIO pin in question and check it with the oscilloscope. If the GPIO does not toggle, this means that there is something forcing the I/O voltage level, or it is unfortunately broken.
2.4. Incorrect oscilloscope or logic analyzer settings (trigger/voltage level etc.)
Users may see a high level on Tx pin but they cannot see the CAN frames on the oscilloscope. They can receive CAN frames on Rx FIFOs but they cannot see any signal on Tx pin. The most probable reason in this case is the tool settings. So, the user needs to set the trigger on rising edge to detect the start bit with a trigger voltage level < VDD. Play with the horizontal cursor to change the time base as the frame can be hidden due to the large time scale.
2.5. Bad CAN BS1 and BS2 parameters values for TSEG1 and TSEG2
Many users fall into the issue of a failing transmit because the timing parameters are not well selected especially where TSEG1 and TSEG2 have very low values. Like TSEG1 = 1 and TSEG2 = 1. The user needs to increase TSEG1 and TSEG2 as much as possible. Decrease CAN clock prescaler as much as possible where TSEG1 = (70 to 85%) x (1+TSEG1+TSEG2), that is, a sample point placed at 70-85% of the bit time.
3. Troubleshooting CAN frames on reception
The most common issues faced on CAN is on the reception. Identifying the issue in Loop Back mode is easier than in Normal mode. That is why before to start CAN application development, it is recommended to start with Loop Back mode and validate your software before going ahead with Normal mode. This is because in Normal mode, there are more issues to identify either on software or on hardware than in Loop Back mode.
3.1. Filter configuration
One of the failing CAN frame receptions is that the frame does not match the filter mask configuration, or the filter bank is not set correctly. If the user has a doubt regarding the filter set, they need to start by setting "passing all ID" config filter that is, all filter ID to 0:
sFilterConfig.FilterIdHigh = 0x0000;
sFilterConfig.FilterIdLow = 0x0000;
sFilterConfig.FilterMaskIdHigh = 0x0000;
sFilterConfig.FilterMaskIdLow = 0x0000;
This allows him at least to bypass the filtering and confirm that he can receive any CAN frame. If with this “passing all ID” configuration he still not receiving any frame, this means it is not due to a filter ID configuration issue but to something else.
For filter bank settings, refer to this article on filter bank. The article explains the filter bank configuration associated with a given Rx FIFO and its relation between the CAN instance used as well as the slave start filter bank parameter. If one of the parameters is not well configured, no CAN frame is received even if the filter ID settings are correct.
3.2. Wrong GPIO pin configuration or missing pull-up resistor on CAN_Rx pin
One of the most probable reasons for failing CAN Rx is the fact that the user did not set a pull-up resistor on the Rx pin. In fact, on all STM32 having bxCAN peripheral, CAN_Rx pin must pulled-up to VDD either by setting the internal pull-up resistor or adding an external pull-up resistor on it.
3.3. Rx interrupt not triggered
If the user is using interrupt instead of polling to receive CAN frame and the interrupt is not fired, they need to check if the NVIC is enabled as well as the correct interrupt CAN FIFO is enabled. The user needs to check if the correct interrupt is enabled for the correct FIFO assigned to the given filter. Additionally, check if the correct CAN Rx FIFO interrupt callback is used.
Let us take an example: one needs to receive a CAN frame using an interrupt on FIFO 0:
NVIC configuration must be set. It is a common NVIC interrupt line for both FIFOs (FIFO 0 and FIFO 1):
HAL_NVIC_SetPriority(CANx_RX_IRQn, <any value>, <any value>);
HAL_NVIC_EnableIRQ(CANx_RX_IRQn);
The correct FIFO number must be assigned to the current filter. In this case FIFO0.
sFilterConfig.FilterFIFOAssignment = CAN_RX_FIFO0;
Enable CAN Rx interrupt on pending message on FIFO0:
HAL_CAN_ActivateNotification(&CanHandle, CAN_IT_RX_FIFO0_MSG_PENDING);
Using the correct callback for FIFO 0:
HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan)
4. General CAN issue troubleshooting recommendations
Troubleshooting issues on Loop Back mode is easier than in Normal mode. The user needs to start with the test mode before going ahead with Normal mode, as its debug is more complicated. It depends on the hardware and on other nodes connected on the CAN bus.
To troubleshoot efficiently, the user needs to simplify the code as much as possible. Complicated code makes the debug more difficult. If any of the relatively complex middleware like FreeRTOS™, TouchGFX, LWIP etc. are used, they need to be removed. Furthermore, remove other peripheral configurations and functions. Focus on the CAN function to ease the debugging process, or simply start a very simple project where the CAN code is isolated to debug it.
What we recommend to any user before posting their issue in the community, is to simplify as much as possible. Additionally, confirm that the issue can be reproduced with a very simple project that can be attached to the thread so we can easily look at it.
