Hi everyone,
I have a problem while configuring CAN messages reception over interruption. I think the problem is related to hardware objects, I am sharing pictures of the config for better understanding.
The point is I have 3 CANbus configured to both send and receive data, so I have configured 6 can hardware objects as follows.
So 3 of them are for transmiting (no problem at this point) and 3 for receiving. As you can see in the picture above, the last parameter of each hw object is "Can Hw Object Count". Here I configured the number of expected messages for each bus, depending on whether they are TX or RX.
This seems to work well with TX messages, but not with RX messages as I am getting the next error at Tresos.
So according to that description, "Can Hw Object Count" must be set to 1, which was the original config I had. The problem is with that config I didn't receive messages at all, I assume because the message buffer is limited to a single message.
My question is, is it really necessary to define a can hardware object for each RX message? Is not possible to declare a value other than 1 at object count parameter? Otherwise I should have to define at least 56 hw objects, which apart from being inefficient, it would also be confusing as there is no way of knowing which object corresponds to which message (and thus, to which bus).
Thanks in advance, let me know if more info is required.
Hello,
What you are highlighting at line 236 is an important clue.
That value to which the variable "length" is compared, represents the size of the 4th output of the CanIf_RxIndication Interrupt Callback block.
In this case, it looks like the size of the "Data" is 1, which means that only one byte of data is transferred through that output.
To fix this. I suggest that you have a look at the s32k344_can_fd_echo_ebt example from the toolbox:
Hello AsierMaser,
Each Tx message requires a dedicated hardware buffer because transmission is an active process where the controller must ensure message arbitration, timing, and retransmission if necessary.
The CanHwardwareObject is the description of the physical CAN message buffer used for transmission and you can have more than one instance of this description based on the needs of your application.
The CAN HW Object Count for Tx specifies the number of dedicated Tx hardware message buffers (instances of CanHwardwareObject) needed for outgoing messages.
For normal Rx objects, CAN controllers use a filtering mechanism to direct incoming messages to a common buffer or directly to software, rather than requiring a dedicated hardware buffer for each Rx message.
This reduces hardware complexity, as incoming messages are typically processed and stored in software-managed queues in your application.
The filtering mechanism from each CanHwardwareObject must be optimally set so that the load on each message buffer can be handled correctly and on time. This eliminates the need for having more than one instance of the CanHwardwareObject (message buffer). For this reason CAN HW Object Count for Rx objects can only be 1.
I recommend reading this article (with focus on subchapter 2.3.2. CanHardwareObject) written by our team that can clarify how the filtering mechanism works:
Communicating over the CAN Bus.
Enhanced or Legacy FIFOs are the exceptions where hardware queues are used for Rx, requiring a count. For these type of objects, the CAN HW Object Count can be increased.
Thanks for your detailed explanation Adrian.
That makes much more sense and aligns with what I was thinking. Just to be sure, I have never used filter mask on Simulink programs, neither in programs are currently running, so I assume it is not mandatory even though it is recommended, is that correct?
Regarding the issue, I find out that Interruptions are not entering the corresponding subsystems, which is dependant of the hardware object.
So subsystems are triggered depending on the value of the hw object, but even with a single bus running the subsystem is not triggered.
Disabling the trigger (regular subsystem) the messages are received correctly. I will investigate about this when I come back from Christmas holidays.
BR
I update with new information after some testing.
I noticed that the received data was always on the first byte of the messages, so analyzing the generated code this is what I saw.
So first the Data array is cleared and then a memory copy is done to that array, from the data obtained in the interruption handler. The problem here is that even the message's payload is 8, just 1 byte is copied to the data array.
After that I checked the interruption handler, and this is what I got.
As you can see at line 236, there is an if that limits the payload of the data to 1 byte. Now my question is, why is this happening? It may be a config error, but I am sure that I defined the payload to 8 on the Can_43_FLEXCAN driver.
BR
Hello,
What you are highlighting at line 236 is an important clue.
That value to which the variable "length" is compared, represents the size of the 4th output of the CanIf_RxIndication Interrupt Callback block.
In this case, it looks like the size of the "Data" is 1, which means that only one byte of data is transferred through that output.
To fix this. I suggest that you have a look at the s32k344_can_fd_echo_ebt example from the toolbox:
Hello,
If you are referring to this EBtreos setting:
this is the size of the memory area allocated for the Rx message buffer. This does not reflect the actual data size of the incoming CAN messages, it acts more like an upper limit.
You can extract the actual data length of the CAN message using the 5th output port of the CanIf_RxIndication Interrupt Callback block:
