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
Hi Adrian,
Thanks for the reply and happy new year! I did not explain myself properly about filter mask, what I meant to say is that I did not configure the default setting, so all the incoming messages were accepted. This is basically what you said, so I guess it is fine.
I am not sure about CanIf_RxIndication. When I configure the ISR block there is an option for transmit messages (CanIf_TxConfirmation) and another for receive messages (CanIf_RxIndication). Is this statement wrong?
My thinking was that as soon as a message is received the CanIf_RxIndication would trigger the ISR and depending on the HW object ID I could know which bus caused the interruption. Then I could handle the data inside the corresponding block, as seen in my previous post images.
I am going to be busy this week and the next, but as soon as I can do some testing I will get back to you.
BR
Hi Adrian,
Sorry for the delay, I have been busy lately. I did not do so much testing, but I noticed that even removing conditional trigger for each bus subsystem, the messages are not being received properly.
This is weird because, for a given CAN message, there are signals that are being processed properly and other that are being omited. CANalyzer software is showing the correct data, so I can guarantee that the problem is in the VCU.
I restored the triggered subsystems and configured them as atomic, as maybe it was a execution problem, but the behaviour is the same as non-atomic (at least I see no difference).
I am not sure if it is a configuration problem (Tresos) or software problem, but the code is correct to my eyes.
I could share the blocks related to CAN reception or Tresos config if you find it helpful, but I would need a secure link to do so.
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 Adrian,
It did work! Now messages are receiving correctly and the bus management is working fine.
However there is something I don't really understand. IRQ handler takes the data from CAN MB every time RX reception flag is set. This CAN data size is configured in Tresos to be 8 bytes, and given that IRQ itself has no data or size, how is it possible to just take a single byte unless you specify the correct legnth of the data (which is already configured in Tresos)?
Thanks for your support,
BR
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: