Model-Based Design Toolbox (MBDT)のトピックRe: Can_message_in_queue

Can_message_in_queue

Vijay98 — Mon, 04 Nov 2024 05:17:59 GMT

Hello NXP team,

Currently we are facing an issue with Can message transmit in queue with single interrupt block.

We need to transmit 2 data in same message id with the same interrupt block in same millisecond

and the message we received is checked using PCAN device.

the message that we send in second block is not received properly (second message is randomly received).

We tried with changing the pdu id value from 0,1,2. but the second message is randomly received.

And if we want to send multiple data using same interrupt block, is there any configuration setting is required?

And We need to transmit different data in different message id with different scheduling time (1ms,2ms,5ms) without any data loss (message loss in some ms). for this any configuration required.

Kindly help us to resolve this issue.

Thanks & regards,

Vijay

@Adrian_Gherca @DrKarthi @Kavin_raj_mbd

Re: Can_message_in_queue

Adrian_Gherca — Mon, 04 Nov 2024 16:07:45 GMT

Hello,
Here are three methods to improve the rate of CAN messages transmission:

1) If you want to trigger the transmission of two CAN messages in the same Gpt_PitNotification 1ms notification, which is the case in model provided in your attachment, you could modify the Pdu ID, but in such a way that one Can_Write block has the value 0 and the other one 1. It is important that those blocks that must transmit at the same moment in time have different Pdu IDs.
This, as you mentioned, will queue the two messages to be transmitted when the CAN bus is free.
Since the Step time of your model is also 1 ms, I would strongly recommend assigning another Pdu ID to the Can_Write that is located in the main Simulink canvas of your model, under Can_module.

2) A better way, I would say, is to trigger the transmission of the first queue message in the Gpt_PitNotification and then transmit the rest of the queue in the CanIf_TxConfirmation, block, which is already present in your model but not actually used.
This means that you should keep only one Can_Write block in the Gpt_PitNotification IRQ Handler, with Pdu_ID value e.g. 0 for that first message, and then in the CanIf_TxConfirmation IRQ Handler create a logic for transmitting the rest of the queue.
By doing so, whenever a transmission finished notification callback is executed, another transmission can be immediately triggered without wasting any time.

In the TX_Complete_Event function you can also implement that logic to check the Pdu_ID, to make sure that you are in the right interrupt for transmitting the desired next message in queue.

3) For each CAN message you could use another CanHardwareObject, which I see you have already plenty configured in the S32 Configuration Tool. Important thing here is to choose those who use interrupt, not polling, as processing type:

Re: Can_message_in_queue

Vijay98 — Tue, 05 Nov 2024 07:44:41 GMT

Hello @Adrian_Gherca

Thank you for your response

We doubt that in three methods that you mentioned, 1 & 2 method is not working

we tried all the three methods, but we don't know whether we are making any mistake in 1 & 2nd method. But we followed the methods as you mentioned

In 1st method, we changed the pdu id for different message and for different can_write block with the same interrupt in same Gpt_1ms task

but we got only one message (verified using PCAN device)

Kindly help us to resolve this issue.

That we have to send multiple data in single can interrupt (Can_write block) in same ms without any data loss.

Thanks & regards,

Vijay

Re: Can_message_in_queue

Adrian_Gherca — Thu, 07 Nov 2024 08:43:02 GMT

Hello,

In order for these to work you also need to increase the number of CAN message buffers available for transmission.
You can do that through the "Can Hw Object Count" setting in S32 Configuration Tool:

Re: Can_message_in_queue

Vijay98 — Fri, 15 Nov 2024 09:51:06 GMT

Hello @Adrian_Gherca

Thanks for the reply

We have checked the "Can Hw Object Count" and changed to 6

1.Now that can message, we are trying to send 4 can message in gpt 1ms is seen in PCAN but the time 1ms is not we are getting.

In Model - 1ms gpt function call system

In peak can output - cyclic time is getting only 0.2 ms

but i can able to receive 4 can messages in single interrupt

This is the one issue we are facing right now

2. Another issue is that with this same 1ms gpt - 4 can message, i have configured 2 can messages in another gpt with different msg id with different can interrupt and can hardware object id is 6.

but for that output of peak can is not getting the 2 can message but the cyclic time is changed to 0.2ms

And i have attached the video of these PCAN output and our file with this post.

Kindly help us to resolve this issue.

Thanks & regards,

Vijay

Re: Can_message_in_queue

Vijay98 — Wed, 20 Nov 2024 16:42:46 GMT

Hello Nxp team,

Any update on our previous post for Can message transmit in gpt?

Kindly help us to resolve this issue.

Thanks & regards,

Vijay

Re: Can_message_in_queue

Adrian_Gherca — Fri, 22 Nov 2024 15:40:29 GMT

Hello,

Regarding the issues you described:

1) I don't see any issues here, all the CAN messages with ID 100 (0x64) from the Task_1ms block, seem to be transmitted correctly in the approximate 1 millisecond time interval.
This can be seen in the Trace view snippet you attached.

The "cyclic time is getting only 0.2 ms" you mentioned is perfectly correct.
It is the Cyle time of the CAN message with ID 100 (0x64) received by the PCAN-View tool.
The data it contains is not relevant when calculating the Cycle Time, only the CAN ID.

When you send 4 CAN messages all with the same standard CAN ID 100 (0x64) in one millisecond you can expect that the Cycle Time displayed in the PCAN-View tool is 0.20ms.
In reality it should actually be 0.27 ms (for 500 kbit/s Bit Rate) but it looks like there is some precision loss here.

2) Please explain more clearly this line:
"but for that output of peak can is not getting the 2 can message but the cyclic time is changed to 0.2ms".
Both CAN messages can be seen in the video can_queue_1:

There are some differences between the model in attachment Can_Quene 2.zip , and the pictures you provided:

To me, it looks like a similar situation as in 1).
Please check the Trace view to better observe the exact time interval between each transmission and also make sure that the second timer is correctly configured and triggered at the right interval.