Inconsistent Controller ID and Hardware Object ID

[Wei_H]

Hi, I have noticed a issue when using S32k344, that is, controller ID and Hardware Object ID does not match for the corresponding CAN message origin.

In the configuration for can controller, can 0 to can 5 are assigned controller ID from 0 to 5 respectively.

In the CanHardwareObject, I have set can 2, 3, 4, 5, 6, 7 to be receive interrupt for CAN 0 to CAN 5 respectively.

Therefore, with the above set up, I'm expecting the receive block will get this:

ControllerID	0	1	2	3	4	5
CanHardwareObjectID	2	3	4	5	6	7

Normally, this work as expected.

However, there are accumulative cases where controllerID and canHardwareObjectID that does not match the origin of the CAN message.

For example, I have received can controllerID 3 with CanHardwareObjectID , controllerID 3 with CanHardwareObjectID 2, controllerID 2 with CanHardwareObjectID 3, controllerID 2 with CanHardwareObjectID 2.

This has serious implication since this mean that the CAN message are no longer reliable due to data being incorrect. Is there something I have configure correctly? I have attached the project that encounter this issue. Thanks! 

[Adrian_Gherca]

Hello,

CanHardwareObjectID and its associated CanControllerID are both provided in Simulink by the Interrupt block CanIf_RxIndication, which you already highlighted in this thread.

In order to be completely sure that there is an inconsistency between the CanHardwareObjectID and its associated CanControllerID,
one must also make sure that the methods used for analysing this issue are capable of capturing this event and deliver all the related data before the next CAN message receive event occurs.

As I can see in the model from the first attachment you provided, all the information regarding the CAN messages, is further transmitted via the UART interface for analysis.
This method of analysing the CAN signals is highly dependent on the rate at which the CAN messages are received and the speed of the UART communication.
If not enough time is allowed for the UART_SyncSend block to finish the transmition of all the bytes in the message, then the next UART_SyncSend call will overwrite the output buffer, hence corrupting the data.
The fact this incosistency is intermitent ("there are accumulative cases where controllerID and canHardwareObjectID that does not match the origin of the CAN message") most likely indicates an issue with the UART communication.

In the model from the second attachment I assume that you are using FreeMASTER and volatile variables for monitoring the information about the CAN messages.
Not sure how one can keep track of which CanHardwareObjectID is associated to which CanControllerID in this manner. Please also take into consideration the refresh rate of the variables in the FreeMASTER PC application.

In order to test the consistency of the CanHardwareObjectID and the CanControllerID I recommend using the S32 Design Studio debug capabilities.
Please import the generated project from Matlab into S32DS and, after building again the project, start the debugging session using the elf file generated with this second build.
Place a brakepoint at the beginning of function CanIf_RxIndication.
Whenever a message is received, the input parameter called "Mailbox", will provide the needed information about the CAN message:
data, id, ControllerID, HardwareObjectID, etc.

[Wei_H]

Hello,

We have resolved the issue by creating a buffer through the use of local variable. Here's the process that we reached to this solution:

We assume that the cause of data inconsistency is the use of pointer when receiving the CAN message. This means that the interrupt occurs but the message in the memory layer has already changed, which caused what what appears to be data inconsistency. Therefore, adding a local variable has allow us to buffer the CAN message, which avoided any change by the time interrupt occurs.

What we learned from this issue, is that the generated code from MBDT may not always be rigorous, which puts the quality of the generated code in questions. Or it can also be incorrect setting in the AUTOSAR configuration that goes through without any warning. But either way, a bug occur that require manual correction to be fixed, which means the MBDT code generation workflow might an update to address this issue.

We will continue to investigate this issue due the uncertain severity it can lead to in the future in our product.  This workaround work for us, but this lead us to question quality in generated code for this line of product. let me know if you have any suggestion on this issue.

Thanks!

[Adrian_Gherca]

Hello and thank you for your response.

The pointer you mentioned is most likely the mailbox that points to the memory location where all the information about the received CAN message is stored.
Consistency between CanHardwareObjectID, the corresponding CanControllerID, CAN ID, data and so on, is only guaranteed at the time when the interrupt CanIf_RxIndication is triggered. It is good practice to first store this information whenever the receive interrupt occurs and use it later outside the interrupt routine.

In order to better understand the problem, can you please mention where exactly did you implement this local variable that acts as a buffer? In the interrupt callback of the Simulink model or in which C file from the the generated code?

[Wei_H]

The two files that we update is the mrcanhubk344_can_s32ct.c and mrcanhubk344_can_s32ct.h.

First, in the header file, we comment out lines indicate by the blue line, and added a new typedef struct indicate by the red bracket.

Then, in the main file, we added the a line underline in red, and update everywhere else to the new typedef in blue.

My explanation may be not be very clear, let me know if you can understand the update and its purpose.

Thanks!

[Adrian_Gherca]

Thank you very much for all the details you provided.

In the original generated code, the buffer used for storing the CAN message information pointed to by the mailbox pointer, is instantiated in the RAM memory (BSS or data) - B_mrcanhubk344_can_s32ct_T mrcanhubk344_can_s32ct_B;  - declaration placed at the beginning of the mrcanhubk344_can_s32ct.c file.

The modification to the generated code you introduced, places the buffer on the Stack memory - B_mrcanhubk344_can_s32ct_T_Ex mrcanhubk344_can_s32ct_B_Ex declaration is now placed inside the callback function CanIf_RxIndication in that same .c file.

It's not clear what exactly is the impact of moving the buffer from global memory to Stack, but I'm happy it fixes the problem.

The model from the attachment Article 4 - MR-CANHUBK344_CAN (2) cannot be built.
For further investigation please provide a complete project that can be built successfully and please mention the Matlab release version used (I assume R2024b) and the version of the NXP_MBDToolbox_S32K3xx add-on.

[Wei_H]

Hi,

I attached a new file that should work. The Matlab verision is 2024b, and the add-on should be NXP_MBDToolbox_Sk32k3xx version 1.5 and NXP_Support_Package_Sk32k3xx version 1.5.

[Adrian_Gherca]

Hello Wei_H,

After managing to run the last attachment you provided on the MR-CANHUBK344 evaluation board (which I assume is the board that this example was configured for), I have a couple of mentions:
- In the table where the expected ControllerID is mentioned with respect to the CanHardwareObjectID, the ControllerIDs with numbers 4 and 5 are present but in this particular attachment these two are not initialized (in the first attachment they were initialized).
- CanController 0 is configured to a BaudRate of 250 Kbps, which is different from the BaudRate of all the other CanControllers configured at 500 Kbps.

In my setup the first 4 Flexcan instances (with ControllerIDs 0, 1, 2 and 3) are all connected to the same physical bus and all work at 500 Kbps BitRate.

As you can see in the attached pictures multiple CAN messages are sent at intervals of less than 1 ms for a long period of time and still, CanHardwareObjectID allways corresponds to the ControllerID.

All 4 CanControllers receive messages but ctrlErrOut is always zero (represented with light green). In the above picture, the canHardwareObjectId (represented with red) is always 2 units greater than ControllerId (represented with blue) which means that the CanHardwareObject always corresponds to the correct CanController.
I also tried with different optimization levels but got the same results.

Can you please confirm that the hardware you are using is the MR-CANHUBK344 evaluation board ?
If the case, can you please mention a certain sequence of messages that are being sent to this board that might trigger the behaviour you complained about?

Regards,
Adrian

 

[Wei_H]

Correction for paragraph*

For example, I have received can controllerID 3 with CanHardwareObjectID 3 instead of 1, controllerID 3 with CanHardwareObjectID 2 instead of 1, controllerID 2 with CanHardwareObjectID 3 instead of 0, controllerID 2 with CanHardwareObjectID 2 instead of 0.

[Wei_H]

Updated,

I noticed the file I upload doesn't work consistently, here's another file that demonstrate the error.