Simulink CAN timeout on embedded coder

Hello,

I am coding in Simulink using c2800x package, Embedded coder and Vehicle Networks Toolbox. I am using CAN bus in my application. What I could not solve is how to detect that I didnt receive message in some time (timeout. My code model is encapsulated in function call block of 100hz. Each eCAN receive block has its function call that calls can unpack. I tried to use CAN unpack timestamp or cantimeout block but it doesnt work on target. So I was trying to run some type of down counter outside of the can handling function block and reset it always when can message is received. Actually I didnt found any way to reset the counter out of the CAN receive function call. Mostly it wanted to use transition block which is not suitable. Any suggestions how to get some type of normal simulink signal out of that call or other way around?

Thank You for help.

[Naini Dawar]

Hey Marek Laszlo,

Could you find a solution for this?

Regards

[Marek Laszlo]

Hello,

Unfortunately I Didnt but I havent been looking for long because the project stopped at that time. So its still actual and would be happy if someone found how to deal with it.

[Birdman]

Hi Marek,

Can you share the simulink model(export to R2017a)?

Answer 1

[Marek Laszlo]

I used TI F28337 MCU that unfortunately doesnt have enhanced CAN module. Only the CAN module. This is unfortunately the reason why you cant receive a message timestamp even if you check it in your receive block.

Answer 2

[Venkatesh Chilapur]

You can create a counter and reset it when you get a CAN message (from the function call of the CAN block or an interrupt). If the counter reaches the timeout value before a CAN message is received, then we can trigger a specific subsystem.

[Marek Laszlo]

Thank You. I tried this and similar solutions but all failed on the function caller. The problem I could not solve and found other poeple asking for is how to reset the counter if you have only the function caller signal. The ports are imcompatible.

Answer 3

[Honey Kethan]

I am using a TI C2000 F280049C and was trying to do the same detect CAN Timeout, But I tried multple methods like

1) Post Intrupt when message is received on CAn RX block

2) Output Timestamp CAN unpack block

3) Output status on CAN unpack block

4) Reset Values to 0 on CAN Rx block

But none of the methods worked, To implement a times, I have to atleast know when message is received, But unfortunately was not able to do it on the hardware using Simulink blocksets, It basically shows the last value it has received and will not give any output related to new message received.

As in my application I am working is safety critical implementation this has been a major hardpoint for me, I am looking for some help with this. Would apprecite if anyone yould help

Answer 4

[Honey Kethan]

I had raised this issue with the Matworks Technical Support Team, The suggested method for implementing timeout is as below, Aparently the methods which we used or tied were not the only available.

Based on the described behavior, the key point is that the CAN Receive block and the CAN Unpack block should be treated separately for timeout detection. The “Reset all fields to zero” option on the CAN Receive block resets the received CAN message structure when no new message is available. However, the downstream CAN Unpack block performs internal validation before updating its output signals. If the received message has an invalid ID or a message length of zero, the CAN Unpack block does not update its decoded outputs and may continue to hold the last valid unpacked values.

Therefore, the CAN Unpack output signals should not be used by themselves to determine whether a new CAN frame has arrived. The recommended approaches are as follows:

Approach 1: Use the MessageLength output from the CAN Receive block

Enable the MessageLength output port on the CAN Receive block and use it as the indication of newly received data. For example:

MessageLength > 0 -> new CAN message received

MessageLength == 0 -> no new CAN message received

A timeout counter can then be implemented as follows:

If MessageLength > 0:

Reset timeout counter

If MessageLength == 0:

Increment timeout counter

If counter reaches threshold:

Set CAN timeout fault

For example, with a 10 ms monitoring rate and a 1 second timeout requirement, the threshold would be 100 samples.

Approach 2: Use the function-call output port from the CAN Receive block

The CAN Receive block function-call output is triggered only when a new CAN message is received. This can be used as a reliable event indication. One possible implementation is:

CAN Receive f() output -> Function-Call Subsystem

Inside subsystem:

Set rxFlag = 1

Then, in a periodic monitoring subsystem:

If rxFlag == 1:

Clear rxFlag

Reset timeout counter

If rxFlag == 0:

Increment timeout counter

If counter reaches threshold:

Set CAN timeout fault

The rxFlag can be implemented using a Data Store Memory block at the model root, with deterministic scheduling between the function-call subsystem and the periodic monitor. For the event-triggered fault message case, the stale fault indication is also explained by the same behavior. Since the CAN Unpack block may continue to hold the last decoded value, the decoded fault value should be qualified using a freshness or timeout signal. The recommended logic is:

If new message is received:

Update fault status from decoded CAN data

If no message is received and timeout expires:

Clear the fault status or mark the signal as invalid

In other words, the application should not rely only on the CAN Unpack output to determine the current fault state. The decoded value should be used only when the corresponding CAN frame has been freshly received. If the message stops arriving, the timeout logic should clear or invalidate the last received fault value as required by the application safety logic.