Hello NXP Community,
We are currently experiencing an issue receiving CAN messages on the RD‑K358BMU evaluation board. We attach all the files in the CAN.zip.
Setup Overview
We are using a custom Simulink model (CAN_Model.slx) which we can successfully flash onto the board; as S32 configuration file, we use the .mex configuration file of the example k358bmu_read_s32ct.mdl for our board, where the CAN 0 channel should be set to both transmit and receive CAN signals.
Moreover, we connected the board to a Vector CANcase and CANoe to monitor CAN traffic.
We created a simple DBC file defining one message (LED) containing two boolean signals to control the red and green LEDs on the board.
Transmit Direction (Board → CANcase) — Working Correctly
In this test, we comment the CAN_Read block in the Simulink model CAN_Model.slx and uncomment the CAN_Write block; then, we flash the code to the board; hence, no message is sent from the CANcase to the board.
We can send correctly the CAN message from the board to the CANcase. CAN messages are successfully transmitted from the board, as we can see clearly in the CANoe Trace window in the attached image.
Receive Direction (CANcase → Board) — Not Working
In this test, we comment the CAN_Write block in the Simulink model CAN_Model.slx and uncomment the CAN_Read block; then, we flash the code to the board; hence, no message is sent from the board to the CANcase.
In our CANoe configuration (attached project CANoe_Config.cfg):
- We added a CAN Interactive Generator that periodically sends the LED message toward the RD‑K358BMU.
- In the CANoe Trace window, the transmitted messages appear correct and no CAN errors are reported.
Unexpected result
However, the message does not seem to be correctly received by the board because the red and green LEDs do not turn on as expected.
Could you please tell us what is the issue here?
Hello,
I've downloaded and checked your example. It seems to work as you described. The problem you encounter seems to be related to the can hardware filters for the CanHardwareObject used to receive the message.
In the default configuration the following happens:
- Messages with the ID in the range 3F0 - 3F7 are processed by the CAN_VCU_Rx_FIFO hardware object only if the Message Type is STANDARD.
- Other messages are processed by the CAN_VCU_Rx_Ext_Interrupt hardware object only if the message received is EXTENDED. Even though in the configuration the CAN ID Message Type is set to MIXED, the received message is going to be treated as EXTENDED.
To solve your problem there are multiple options:
- Set the CAN Message Type to STANDARD for the CAN_VCU_Rx_Ext_Interrupt hardware object to process all incoming standard message, if you are not interested in extended.
- Set all the messages in the CAN dbc as EXTENDED.
In your case, if I send an extended CAN message with ID 0x1, the LEDs turn on. The same applies if I send a standard CAN message with ID 0x3F0.
Another important aspect is that you need to make sure the Can Hw Filter Code and Can Hw Filter Mask are properly set for each CanHardwareObject. A message is received if the following rule is true (bitwise operations), otherwise the CAN message is discarded.
RECEIVED_ID & FILTER_MASK = FILTER_CODE & FILTER_MASK
Best regards,
Sorin Bancila
