TDA4VM: CANFD has been in the receiving state for a long time, please help to solve the confusion

Hi TI,

Dump Register when abnormal, for reference：

[MCU2_1]     38.809559 s: cfg:0x2771000:0x32380608 ss:0x2770000:0x68e04901
[MCU2_1]     38.809597 s: cfg:0x2771004:0x87654321 ss:0x2770004:0x38
[MCU2_1]     38.809629 s: cfg:0x2771008:0x0 ss:0x2770008:0x6
[MCU2_1]     38.809659 s: cfg:0x277100c:0x830612 ss:0x277000c:0x0
[MCU2_1]     38.809691 s: cfg:0x2771010:0x0 ss:0x2770010:0x0
[MCU2_1]     38.809721 s: cfg:0x2771014:0xffff ss:0x2770014:0x0
[MCU2_1]     38.809752 s: cfg:0x2771018:0x340 ss:0x2770018:0x0
[MCU2_1]     38.809783 s: cfg:0x277101c:0x10031e07 ss:0x277001c:0x0
[MCU2_1]     38.809816 s: cfg:0x2771020:0xe0000 ss:0x2770020:0x0
[MCU2_1]     38.809847 s: cfg:0x2771024:0x0 ss:0x2770024:0x0
[MCU2_1]     38.809878 s: cfg:0x2771028:0xffff0000 ss:0x2770028:0x0
[MCU2_1]     38.809910 s: cfg:0x277102c:0xffff ss:0x277002c:0x0
[MCU2_1]     38.809941 s: cfg:0x2771030:0x0 ss:0x2770030:0x0
[MCU2_1]     38.809971 s: cfg:0x2771034:0x0 ss:0x2770034:0x0
[MCU2_1]     38.810001 s: cfg:0x2771038:0x0 ss:0x2770038:0x0
[MCU2_1]     38.810031 s: cfg:0x277103c:0x0 ss:0x277003c:0x0
[MCU2_1]     38.810062 s: cfg:0x2771040:0x0 ss:0x2770040:0x0
[MCU2_1]     38.810092 s: cfg:0x2771044:0x113017 ss:0x2770044:0x0
[MCU2_1]     38.810124 s: cfg:0x2771048:0x60a ss:0x2770048:0x0
[MCU2_1]     38.810154 s: cfg:0x277104c:0x0 ss:0x277004c:0x0
[MCU2_1]     38.810185 s: cfg:0x2771050:0x20001201 ss:0x2770050:0x0
[MCU2_1]     38.810217 s: cfg:0x2771054:0x1fffffff ss:0x2770054:0x0
[MCU2_1]     38.810250 s: cfg:0x2771058:0x3fffffff ss:0x2770058:0x0
[MCU2_1]     38.810282 s: cfg:0x277105c:0x2 ss:0x277005c:0x0
[MCU2_1]     38.810312 s: cfg:0x2771060:0x0 ss:0x2770060:0x0
[MCU2_1]     38.810343 s: cfg:0x2771064:0x0 ss:0x2770064:0x0
[MCU2_1]     38.810373 s: cfg:0x2771068:0x0 ss:0x2770068:0x0
[MCU2_1]     38.810403 s: cfg:0x277106c:0x0 ss:0x277006c:0x0
[MCU2_1]     38.810433 s: cfg:0x2771070:0x0 ss:0x2770070:0x0
[MCU2_1]     38.810464 s: cfg:0x2771074:0x0 ss:0x2770074:0x0
[MCU2_1]     38.810494 s: cfg:0x2771078:0x0 ss:0x2770078:0x0
[MCU2_1]     38.810524 s: cfg:0x277107c:0x0 ss:0x277007c:0x0
[MCU2_1]     38.810554 s: cfg:0x2771080:0x2b ss:0x2770080:0x0
[MCU2_1]     38.810585 s: cfg:0x2771084:0x804000 ss:0x2770084:0x0
[MCU2_1]     38.810617 s: cfg:0x2771088:0x0 ss:0x2770088:0x0
[MCU2_1]     38.810647 s: cfg:0x277108c:0x0 ss:0x277008c:0x0
[MCU2_1]     38.810677 s: cfg:0x2771090:0x1fffffff ss:0x2770090:0x0
[MCU2_1]     38.810710 s: cfg:0x2771094:0x0 ss:0x2770094:0x0
[MCU2_1]     38.810740 s: cfg:0x2771098:0x0 ss:0x2770098:0x0
[MCU2_1]     38.810770 s: cfg:0x277109c:0x0 ss:0x277009c:0x0
[MCU2_1]     38.810801 s: cfg:0x27710a0:0xa0401b00 ss:0x27700a0:0x0
[MCU2_1]     38.810833 s: cfg:0x27710a4:0x2b15 ss:0x27700a4:0x0
[MCU2_1]     38.810864 s: cfg:0x27710a8:0x2a ss:0x27700a8:0x0
[MCU2_1]     38.810895 s: cfg:0x27710ac:0x900 ss:0x27700ac:0x0
[MCU2_1]     38.810926 s: cfg:0x27710b0:0xa0402d00 ss:0x27700b0:0x0
[MCU2_1]     38.810958 s: cfg:0x27710b4:0x0 ss:0x27700b4:0x0
[MCU2_1]     38.810989 s: cfg:0x27710b8:0x0 ss:0x27700b8:0x0
[MCU2_1]     38.811019 s: cfg:0x27710bc:0x777 ss:0x27700bc:0x0
[MCU2_1]     38.811050 s: cfg:0x27710c0:0x200000 ss:0x27700c0:0x0
[MCU2_1]     38.811082 s: cfg:0x27710c4:0x0 ss:0x27700c4:0x0
[MCU2_1]     38.811112 s: cfg:0x27710c8:0x7 ss:0x27700c8:0x0
[MCU2_1]     38.811143 s: cfg:0x27710cc:0x0 ss:0x27700cc:0x0
[MCU2_1]     38.811172 s: cfg:0x27710d0:0x0 ss:0x27700d0:0x0
[MCU2_1]     38.811203 s: cfg:0x27710d4:0x0 ss:0x27700d4:0x0
[MCU2_1]     38.811233 s: cfg:0x27710d8:0x0 ss:0x27700d8:0x0
[MCU2_1]     38.811263 s: cfg:0x27710dc:0x1 ss:0x27700dc:0x0
[MCU2_1]     38.811293 s: cfg:0x27710e0:0xffff ss:0x27700e0:0x0
[MCU2_1]     38.811325 s: cfg:0x27710e4:0x0 ss:0x27700e4:0x0
[MCU2_1]     38.811355 s: cfg:0x27710e8:0x0 ss:0x27700e8:0x0
[MCU2_1]     38.811385 s: cfg:0x27710ec:0x0 ss:0x27700ec:0x0
[MCU2_1]     38.811416 s: cfg:0x27710f0:0x1f203f00 ss:0x27700f0:0x0
[MCU2_1]     38.811449 s: cfg:0x27710f4:0x160016 ss:0x27700f4:0x0
[MCU2_1]     38.811480 s: cfg:0x27710f8:0x0 ss:0x27700f8:0x0
[MCU2_1]     38.811511 s: cfg:0x27710fc:0x0 ss:0x27700fc:0x0

Hi

I'm not able to fully understand the problem, is it that when you try to do Tx or Rx separately then things work but when you do them together in the periodic tasks you mentioned in that case things start to fail?

The CAN node can either Transmit or Receive at a particular point in time, it can not be Transmitting & Receiving together. This is what is shown by MCAN_PSR's ACT field.

A value of 2 in ACT means that the node is currently acting as a receiver.

MCAN_CCCR register (0x2771018) shows that the DAR bit is set, i.e. there will not be any Automatic Retransmission. Can you make sure that is 0? Making this 0 will let the MCAN controller try retransmitting in case it is not able to.

Regards

Karan

Hello Karan Saxena

I have a similar question about MCAN in SDK 8.2.

The background is below:

1）Introduction to sending messages：2 frames of 10ms periodic message、9 frames of 20ms periodic message、5 frames of 100ms periodic message

2）Introduction to receiving messages：7 frames of 50ms periodic message

The detail info about the problem:

I have monitored one of the 10ms cycle messages,  the cycle time will keeps 10ms for 60 -70 seconds, and then the cycle time will changed like a wave:

Could you please tell me what can I do to solve it?

best wishes

Chengwu.Tang

Hi Karan,

The CAN sending timeout is solved, but there is a phenomenon described by Chengwu, please help to analyze.

Best Regards

Lei

Hi Chengwu.Tang

Chengwu Tang said:

1）Introduction to sending messages：2 frames of 10ms periodic message、9 frames of 20ms periodic message、5 frames of 100ms periodic message

2）Introduction to receiving messages：7 frames of 50ms periodic message

Please let me know if my understanding is correct. On TX you are sending 2 frames with periodicity 10ms, 9 frames with 20ms periodicity adn 5 frames with 100ms periodicity. Meaning, you will get below number of messages:

Is this understanding correct?

Chengwu Tang said:

I have monitored one of the 10ms cycle messages,  the cycle time will keeps 10ms for 60 -70 seconds, and then the cycle time will changed like a wave:

Could you please tell me what can I do to solve it?

Can you help me understand the image you attached?

Regards

Karan

Hi Karan Saxena

I have corrected the tx/rx information as below:

best wishes

Chengwu.Tang

Hi Chengwu.Tang

Karan Saxena said:

Chengwu Tang said:

I have monitored one of the 10ms cycle messages,  the cycle time will keeps 10ms for 60 -70 seconds, and then the cycle time will changed like a wave:

Could you please tell me what can I do to solve it?

Can you help me understand the image you attached?

Can you also help me understand this image you attached?

Regards

Karan

Hi Karan，

1.The ordinate of the above picture is the interval between two receptions of the same message, and the abscissa is the time axis.

2.The problem now is that 10ms is very stable in 160s~190s, but 9.3ms~10.7ms appears in 190s~200s fluctuations,and there are regular fluctuations When there is always a message received on the can bus (cycle 50ms)

3.When no message is received on the can bus,  it will be a straight line, and there will be no fluctuation

BR

Lei

Hi Lei

Seems like at the intervals of 100ms where there are (2 + 9 + 5) messages Transmitted and 7 messages received, in that case there is a burst of high CPU load. Can you check if you still see the inconsistency in the receive task if there are no transmitted messages?

If disabling the Tx improves the situation then there is a problem that the TX and RX together are not able to trigger at exact time due to CPU load. This can be improved however.

Regards

Karan

Hi Karan，

1) The problem does not occur when only TDA4 is sent.

2) If TDA4 only receives, I don't think it can be evaluated. The reason is that the sender is CANOE, it is no problem.

3) "This can be improved however."

    ==> [Lei] Can you introduce?

BR，

Lei

Hi Karan，

Karan Saxena said:

This can be improved however.

Can you introduce?

BR，

Lei

Hi Lei,

You can improve the performance by,

1. Placing the code in faster memory. Also check if your R5F's MPU configurations are appropriate i.e. Cache is enabled.

2. Make sure that the CAN module you are using is from the same domain as the R5F, use MCU MCANs for MCU R5F and MAIN MCANs for MAIN R5F. This would help in reducing latency.

3. Check the MPU settings for the MCAN Message RAM. I’ve seen a lot of improvements is we set CAN message RAM (as seen by the R5F) as device memory instead of strongly ordered memory.

Regards

Karan

Hi Karan,

I don't understand the third item the “device memory instead of strongly ordered”, This means that when we enable the cache(according to the first suggestion), we need to configure the cachePolicy  as CSL_ARM_R5_CACHE_POLICY_NON_CACHEABLE and memAttr as CSL_ARM_R5_MEM_ATTR_STRONGLY_NON_CACHED?

For example the following code?, Can you give me a sample code for configuring mpu?

BR,

Lei

Hi Lei

lei tao said:

I don't understand the third item the “device memory instead of strongly ordered”,

You can refer to the R5F's TRM from ARM. Some information is here - https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Application-Level-Memory-Model/Memory-types-and-attributes-and-the-memory-order-model/Device-and-Strongly-ordered-memory#:~:text=The%20only%20architecturally%2Drequired%20difference,component%20accessed%20by%20the%20write

lei tao said:

For example the following code?, Can you give me a sample code for configuring mpu?

+    {
+        //Region 9 configuration: covers MCU MCAN MSG RAM
+        .regionId         = 9U,
+        .enable           = 1U,
+        .baseAddr         = 0x40500000,
+        .size             = CSL_ARM_R5_MPU_REGION_SIZE_512KB,
+        .subRegionEnable  = CSL_ARM_R5_MPU_SUB_REGION_ENABLE_ALL,
+        .exeNeverControl  = 0U,
+        .accessPermission = CSL_ARM_R5_ACC_PERM_PRIV_USR_RD_WR,
+        .shareable        = 0U,
+        .cacheable        = (uint32_t)FALSE,
+        .cachePolicy      = 0U,
+        .memAttr          = 0U,
+    },

You can add a section like this in the MPU.

Regards

Karan

Hi Karan,

Could you give me a suggestion configuration about the MPU that enable the cache and set the memory type to device memory.

For example, what values do these three (.cacheable / .cachePolicy / .memAttr ) need to be configured to?

Hi

Ruifeng Zhang said:

Could you give me a suggestion configuration about the MPU that enable the cache and set the memory type to device memory.

For example, what values do these three (.cacheable / .cachePolicy / .memAttr ) need to be configured to?

What I mentioned in my previous reply, also quoted below, can be used to configure the MCAN Message RAM as non-shareable device memory.

You need to change the base address, the example is for the MCU MCAN0.

Karan Saxena said:

For example the following code?, Can you give me a sample code for configuring mpu?

Fullscreen

1

2

3

4

5

6

7

8

9

10

11

12

13

14

+ {

+ //Region 9 configuration: covers MCU MCAN MSG RAM

+ .regionId = 9U,

+ .enable = 1U,

+ .baseAddr = 0x40500000,

+ .size = CSL_ARM_R5_MPU_REGION_SIZE_512KB,

+ .subRegionEnable = CSL_ARM_R5_MPU_SUB_REGION_ENABLE_ALL,

+ .exeNeverControl = 0U,

+ .accessPermission = CSL_ARM_R5_ACC_PERM_PRIV_USR_RD_WR,

+ .shareable = 0U,

+ .cacheable = (uint32_t)FALSE,

+ .cachePolicy = 0U,

+ .memAttr = 0U,

+ },

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

+    {
+        //Region 9 configuration: covers MCU MCAN MSG RAM
+        .regionId         = 9U,
+        .enable           = 1U,
+        .baseAddr         = 0x40500000,
+        .size             = CSL_ARM_R5_MPU_REGION_SIZE_512KB,
+        .subRegionEnable  = CSL_ARM_R5_MPU_SUB_REGION_ENABLE_ALL,
+        .exeNeverControl  = 0U,
+        .accessPermission = CSL_ARM_R5_ACC_PERM_PRIV_USR_RD_WR,
+        .shareable        = 0U,
+        .cacheable        = (uint32_t)FALSE,
+        .cachePolicy      = 0U,
+        .memAttr          = 0U,
+    },

You can add a section like this in the MPU.

Regards

Karan

Hi Karan,

Karan Saxena said:

What I mentioned in my previous reply, also quoted below, can be used to configure the MCAN Message RAM as non-shareable device memory.

You need to change the base address, the example is for the MCU MCAN0.

The non-shareable need set .shareable to 0.

.shareable        = 0U,

Karan Saxena said:

1. Placing the code in faster memory. Also check if your R5F's MPU configurations are appropriate i.e. Cache is enabled.

According this, I know need enable cache and the cacheable need set .cacheable to TRUE.  It's different from the code you have shared.

.cacheable        = (uint32_t)True,

But I don't know which value need to set for .memAttr represents the device_memory type ? And does the .cachePolicy need to be changed?

Hi Karan,

We try configure mpu MCAN7/9/11 MSGMEM_RAM cacheable,memAttr in device memory ,as follows,the problem is still there:

Preliminary judgment is related to can bus arbitration:  Could you have suggestions to optimize the periodic message bus arbitration problem?

BR,

Ruifeng

Hi Ruifeng

Sorry for no response on this thread. Can you please confirm if you still need help here?

Regards

Karan

Hi Karan,

Thank you. Not for the time being

BR，

Lei