This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA821U: How to improve buffer full drop

Part Number: DRA821U
Other Parts Discussed in Thread: DRA821, SK-TDA4VM, TDA4VM, DRA829

Tool/software:

Hi,

We did a CAN traffic test.

When CAN RX traffic increases, "msglost in rxf0" occurs.

[  582.783855] m_can_platform 2771000.can can5: msg lost in rxf0
[  582.786916] m_can_platform 2751000.can can3: msg lost in rxf0
[  582.791426] m_can_platform 2701000.can can1: msg lost in rxf0
[  582.794588] m_can_platform 2761000.can can4: msg lost in rxf0
[  582.797610] m_can_platform 2781000.can can6: msg lost in rxf0
[  582.801723] m_can_platform 2771000.can can5: msg lost in rxf0
[  582.804739] m_can_platform 2751000.can can3: msg lost in rxf0
[  582.807791] m_can_platform 2761000.can can4: msg lost in rxf0
[  582.812810] m_can_platform 2701000.can can1: msg lost in rxf0
[  582.815954] m_can_platform 2781000.can can6: msg lost in rxf0
[  582.820506] m_can_platform 2771000.can can5: msg lost in rxf0

The test environment is as follows:

SDK version: 9.01

CAN interface setting

root@vdms:~# ip -d -s link show can1
3: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 65536
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000
          bitrate 500000 sample-point 0.800
          tq 12 prop-seg 63 phase-seg1 64 phase-seg2 32 sjw 1 brp 1
          m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
          dbitrate 2000000 dsample-point 0.750
          dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 dbrp 1
          m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
          clock 80000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 2701000.can
    RX:  bytes packets errors dropped  missed   mcast
       5470760  683845      0    6743       0       0
    TX:  bytes packets errors dropped carrier collsns
             0       0      0       0       0       0
root@vdms:~#

CAN DTS setting

        mcan0: can@2701000 {
                compatible = "bosch,m_can";
                reg = <0x00 0x02701000 0x00 0x200>,
                      <0x00 0x02708000 0x00 0x8000>;
                reg-names = "m_can", "message_ram";
                power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
                clocks = <&k3_clks 156 0>, <&k3_clks 156 2>;
                clock-names = "hclk", "cclk";
                interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
                             <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
                interrupt-names = "int0", "int1";
                bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
        };

Please let me know how to increase CAN traffic processing capacity.

Regards,

dohyeon

  • Hello,

    We did a CAN traffic test.

    Could you explain the test scenario here ? why packets got dropped need to be understood ? Any filters set to receive messages?

    CAN DTS setting

    your dts setting looks good.

    Regards

    Tarun Mukesh

  • Hi,

    The test configuration is as follows.

    Packet generator setting

    Bus load (93%)

    When tested with the above setting, "msglost in rxf0" occurs and CPU usage becomes 100%.

    Please let me know how to increase CAN traffic processing capacity.

    Regards,

    Dohyeon

  • Hello,

    The sampling rates as per your code is different from your configuration in PCAN tool

    bitrate 500000 sample-point 0.800
    tq 12 prop-seg 63 phase-seg1 64 phase-seg2 32 sjw 1 brp 1
    m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
    dbitrate 2000000 dsample-point 0.750
    dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 dbrp 1
    m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
    clock 80000000

    Can you please let me know why the difference exists ?

    Regards

    Tarun Mukesh

  • Hi

    There is no reason for setting it differently. It's a setup error.

    Even if I change it to 75% and test it, I get the same log.

    Regards,

    Dohyeon

  • Hello,

    If still the problem persists , then we you can also check below 2 conditions,

    1. Set the interrupt priority as highest , if the priority is low and if it takes time to serve these interrupts then you can face this issue.Please try to run one CAN instance, only CAN in the example and no other peripherals and see.

    2. Check for low lever filters have you enabled , which blocks certains message ID's etc...

    Regards

    Tarun Mukesh

  • Hi

    1. What are your recommended interrupt priorities?

    2. What "low level filter" are you talking about, for example?

    Regards

    Dohyeon.

  • Hi Tarun Mukesh,

      DoHyeon Kim is my team member. Our customer's requirements is collect all CAN frame without any lost.

      So we should not use CAN RX filter as your suggestion 2.

      How can change the CAN interrupt priority as highest  to collect all CAN frame in DRA821?

      Thanks!

    Regards

    YoungHan Kim

  • Hello Young,

    We have standard ID filter,

    For MCU_MCAN0,at register address 0x4052 8084h we have FLSSA[2-15] bits which denotes message RAM start address in that message RAM start address what's your configuration needs to be known.

    In your configuration , you are running multiple CAN instances at a time right ?. Could you run one instance of CAN and check whether you are still facing the same issue ?

    Regard

    Tarun Mukesh

  • Hi Tarun Mukesh,

     

      AS I MENTIONED THAT OUR CUSTOMER WANT TO RECEIVE ALL CAN FRAME. WE CAN'T USE CAN ID FILTER IN OUR PROJECT!

      Please let me know how can change the interrupt priority of CAN.

      Also DoHyeon will test with one instance of CAN.

      Thanks!

    Regards

    YoungHan Kim

  • Hello Young,

    In your test set up are sending the CAN Test data with different ID's or same ID. Is the other end detecting any errors while the packets are losing ?

    If you dont change any priority all the instances will be the same in CAN

      Also DoHyeon will test with one instance of CAN.

    Please run CAN0 standalone test aand yes after these results only i can suggest more steps to debug.

    Regards

    Tarun Mukesh

  • Hi

    When only 1 port out of 12 ports of CAN (CAN12) is enabled and RX, the same message occurs.

    Does this issue not happen with EVMs?

    Please share the method and test results that can be checked in EVM.

    Regards

    Dohyeon

  • Hello,

    Is it same message ID ?

    Regards

    Tarun Mukesh

  • Hi

    It occurs when the CAN ID is the same, and also occurs when it is different.
    Doesn't EVM have the same problem?
    Please check.

    Regards

    Dohyeon

  • Hello,

    Yes i tried at my end on EVM.

    I am able to successfully receive the messages.

    Regards

    Tarun MUkesh

  • Hi Tarun MUkesh,

      It seems good news.

      Please test with 1 hour. Please check the kernel's message.

      Please share linux command to init CAN interface.

      Also please share the configuration of CAN device (PCAN or CANoe).

     

      As I know, original DRA821 SDK doesn't support linux CAN interface.

      Please provide SD image to us, we will test with DRA821 EVM.

      Thanks!

    YoungHan Kim

  • Hello Young,

    We have FAQ written already, please look into the FAQ and adapt this FAQ.

    e2e.ti.com/.../faq-j7200xsomxevm-how-do-i-enable-can-with-linux-driver-on-j7200

    PCAN i am using at 1 kbps nominal and 5kbps data bit rate.

    Regards

    Tarun Mukesh

  • Hi Tarun Mukesh,

     Thanks we will check the link.

      Please test with 500K and 2Mbps CAN FD.

      And please attach the screen shot.

    Regards

    YoungHan Kim

  • Hello Young,

    Bit rate are given as input on the terminal to operate the CAN .so it is not related to driver configuration.so you please check their are any physical connection due to which Rx packets are dropping.

    Their is no issue in driver as it is working well on TI EVM.

    Regards 

    Tarun Mukesh 

  • Hi Tarun

    This is Jack Cha from Arrow Electronics, who is in charge of Technical Support Representative for Korean Mass Market Regional Sales Team. 

    Could you please more clarify this thread for them to replicate the issue from EVK?

    This is an important request that will determine whether or not the project continues, so please be kind enough to clarify the thread.
    The same request has also been made to the TI BU this week.

    Thanks and Regards, 

    Jack 

  • Hello Jack cha,

    I tried at my end on TI EVM and not able to replicate the packet loss and shared log for it. There is no issue in driver is what i have said to them.

     Do you have any further ideas on this ?

    Regards

    Tarun Mukesh

  • Hi Jack and Tarun,

    Have not seen this behavior before. However, I did some tests with a loopback between two CAN interfaces on EVM (SK-TDA4VM to be exact, since I did not have a DRA821 with me, but software driver is the same). Seems like no issues at bitrate 2Mbps with no dropped packets:

    root@tda4vm-sk:~# ifconfig -a
    can0: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 117
    
    can1: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 584448  bytes 2337792 (2.2 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 120
    
    can2: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 121
    
    can3: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 584448  bytes 2337792 (2.2 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 122
    
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:56:2d:b4  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 92  bytes 7648 (7.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 92  bytes 7648 (7.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    root@tda4vm-sk:~# ip -d -s link show can1
    4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
              bitrate 2000000 sample-point 0.750
              tq 12 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              dbitrate 5000000 dsample-point 0.750
              dtq 12 dprop-seg 5 dphase-seg1 6 dphase-seg2 4 dsjw 1 dbrp 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 2701000.can
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
           2337792  584448      0       0       0       0
    root@tda4vm-sk:~# ip -d -s link show can3
    6: can3: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
              bitrate 2000000 sample-point 0.750
              tq 12 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              dbitrate 5000000 dsample-point 0.750
              dtq 12 dprop-seg 5 dphase-seg1 6 dphase-seg2 4 dsjw 1 dbrp 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 2791000.can
        RX:  bytes packets errors dropped  missed   mcast
           2337792  584448      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
    root@tda4vm-sk:~#
    

    And this was how I set it up:

    1. ip link set can1 type can bitrate 2000000 dbitrate 5000000 berr-reporting on fd on
    2. ip link set can3 type can bitrate 2000000 dbitrate 5000000 berr-reporting on fd on
    3. ip link set up can1
    4. ip link set up can3
    5. candump can3 &

    And to send, I put below in a while loop in a bash script and let it run a while:

    • cansend can1 123##112345678 > /dev/null

    If you have multiple CAN interfaces on your board, you could do a similar loopback test. This could narrow down the issue since it checks if the issue is with the PCAN device to connect your board to a packet generator.

    If you see issues with the loopback test as well, I do see that SK-TDA4VM is using a slightly different CAN transceiver than the DRA821 EVM. That could be the next difference to check.

    Regards,

    Takuma

  • Hi Takuma,

      If refer Dohyeon's test diagram, it is not loopback test. It is similar with real usage case than loopback.

      Please test with Peak CAN, CANoe or Kvaser.

      Thanks for your support.

    Regards

    YoungHan Kim

  • Hi YoungHan,

    I understand that it is not a loopback test and I understand the device is DRA821 instead of TDA4VM. My suggestion is for Dohyeon or you to test out a loopback test on their board that shows the issue as a way to debug.

    This experiment can possibly take out many variables, thereby narrowing down the root cause, and makes it easier for the test to be reproduced by folks that may not have PCAN device (which includes myself). 

    Thank you for your patience on this matter.

    Regards,

    Takuma

  • Hi Takuma

    In the environment I test, the interface setting is bitrate 500 kbps and dbitrate 2 Mbps.
    When transmitted at 1 Mbps (50%) in the packet generator, "m_can_platform 2691000.can11: msg lost in rxf0" log is generated.

    "m_can_platform 2691000.can11: msg lost in rxf0" occurs the same way when Takuma sets the environment, bitrate 2 Mbps, dbitrate 5 Mbps, and proceeds with the same test (1 Mbps).

    In addition, when the same traffic test (1 Mbps) was conducted after connecting 1 CAN interface, "m_can_platform 2691000.can11: msg lost in rxf0" did not occur.
    When testing with only 1 interface, "m_can_platform 2691000.can11: msg lost in rxf0" log is generated when the amount of traffic is raised to 1.8 Mbps (90%).

    Looking at the test contents, it seems that the debug log is output according to the amount of traffic.
    How much traffic bps is the loopback test?
    I want you to test it through the packet generator.

    Regards,

    Dohyeon

  • Hi Dohyeon,

    I will see if there is a tool within our SDK that can generate traffic more consistently. In terms of Mbps for the loopback test conducted, I just stuck the command for sending 1 packet in a while loop, so may not be as reliable.

    In any case though, is it possible to conduct the loopback test on your end as well, so that it takes out the variability coming from the PCAN device? Or is it physically hard due to not having multiple CAN interfaces on your board?

    Regards,

    Takuma

  • Hi Takuma

    I connected the CAN interface as below, and did a loopback test.
    The test using "canend" did not output the message "m_can_platform 2691000.can11: msg lost in rxf0".
    "cangen" can be used to replace the packet generator.
    When tested with "cangen" in the same configuration, a few minutes of waiting resulted in the output of the message "m_can_platform 2691000.can11: msg lost in rxf0".

    root@vdms:~# ifconfig can10
    can10     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              UP RUNNING NOARP  MTU:72  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:65536
              RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
              Interrupt:20
    
    root@vdms:~# ifconfig can11
    can11     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              UP RUNNING NOARP  MTU:72  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:65536
              RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
              Interrupt:21
    
    root@vdms:~# ip -d -s link show can10
    14: can10: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 65536
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000
              bitrate 500000 sample-point 0.800
              tq 12 prop-seg 63 phase-seg1 64 phase-seg2 32 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              dbitrate 2000000 dsample-point 0.750
              dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 dbrp 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 27d1000.can
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
    root@vdms:~# ip -d -s link show can11
    15: can11: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 65536
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000
              bitrate 500000 sample-point 0.800
              tq 12 prop-seg 63 phase-seg1 64 phase-seg2 32 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              dbitrate 2000000 dsample-point 0.750
              dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 dbrp 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 2691000.can
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
    root@vdms:~#
    root@vdms:~# candump -s 2 can11 &
    [1] 663
    [  179.428987] can: controller area network core
    [  179.431300] NET: Registered PF_CAN protocol family
    root@vdms:~# [  179.486412] can: raw protocol
    
    root@vdms:~# cangen can10 -g 0 &
    [2] 683
    root@vdms:~# date
    Fri Jul 19 08:01:54 UTC 2024
    root@vdms:~# [  394.472518] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.475875] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.479026] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.552832] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.557392] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.560663] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.611422] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.615296] m_can_platform 2691000.can can11: msg lost in rxf0
    [  394.618479] m_can_platform 2691000.can can11: msg lost in rxf0
    
    root@vdms:~# date
    Fri Jul 19 08:04:27 UTC 2024
    root@vdms:~#

    Regards,

    Dohyeon

  • Hi Dohyeon,

    Thank you for trying out the experiment and also thank you for finding cangen tool. I’ll try that out and see if I can reproduce the issue.

    Regards,

    Takuma

  • Hi Takuma

    Does the buffer full drop not occur?
    Please share your progress with us.

    Regards.

    Dohyeon

  • Hi Dohyeon,

    Apologies for the delay. May I get back to you on this thread next week?

    Regards,

    Takuma

  • Hi Dohyeon,

    I did some experiments and found some interesting results.

    It looks like "cangen mcu_mcan1 -f -g 0" which uses CAN FD does not cause the "msg lost in rxf0" (or at least, it did not when I was testing for an hour). On the other hand, "cangen mcu_mcan1 -g 0", which removes the -f option for CAN FD, causes "msg lost in rxf0" message.

    Attached below are some logs from my experiment using CAN FD where 91 million packets were sent and received with 0 dropped with cangen:

    tda4vm-sk login: root
    [   39.139983] audit: type=1006 audit(1651199008.688:15): pid=1058 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=3 res=1
    [   39.153355] audit: type=1300 audit(1651199008.688:15): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=ffffd0edfcc8 a2=1 a3=0 items=0 ppid=1 pid=1058 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
    [   39.179038] audit: type=1327 audit(1651199008.688:15): proctitle="(systemd)"
    [   39.186419] audit: type=1334 audit(1651199008.700:16): prog-id=13 op=LOAD
    [   39.193531] audit: type=1300 audit(1651199008.700:16): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=fffff31ba110 a2=78 a3=0 items=0 ppid=1 pid=1058 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)
    [   39.219191] audit: type=1327 audit(1651199008.700:16): proctitle="(systemd)"
    [   39.226552] audit: type=1334 audit(1651199008.700:17): prog-id=13 op=UNLOAD
    [   39.233651] audit: type=1334 audit(1651199008.700:18): prog-id=14 op=LOAD
    [   39.240648] audit: type=1300 audit(1651199008.700:18): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=fffff31ba1b0 a2=78 a3=0 items=0 ppid=1 pid=1058 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)
    [   39.266348] audit: type=1327 audit(1651199008.700:18): proctitle="(systemd)"
    root@tda4vm-sk:/opt/edgeai-gst-apps# cd
    root@tda4vm-sk:~# ls
    while_send_can1.sh
    root@tda4vm-sk:~# ip link set can1 type can bitrate 2000000 dbitrate 5000000 berr-reporting on fd on
    root@tda4vm-sk:~# ip link set can3 type can bitrate 2000000 dbitrate 5000000 berr-reporting on fd on
    root@tda4vm-sk:~# ip link set up can1
    [   60.862618] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
    root@tda4vm-sk:~# ip link set up can3
    [   62.162014] IPv6: ADDRCONF(NETDEV_CHANGE): can3: link becomes ready
    root@tda4vm-sk:~# ifconfig can1 txqueuelen 1000
    root@tda4vm-sk:~# ifconfig can3 txqueuelen 1000
    root@tda4vm-sk:~# ifconfig
    can1: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 119
    
    can3: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 122
    
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:56:2d:b4  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 92  bytes 7648 (7.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 92  bytes 7648 (7.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    root@tda4vm-sk:~# candump can3 > /dev/null &
    [1] 1146
    [   77.710020] can: controller area network core
    [   77.714446] NET: Registered PF_CAN protocol family
    root@tda4vm-sk:~# [   77.724809] can: raw protocol
    
    root@tda4vm-sk:~# cangen can1 -f -g 1
    ^Croot@tda4vm-sk:~# ifconfig
    can1: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 3439  bytes 55527 (54.2 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 119
    
    can3: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 3439  bytes 55527 (54.2 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 122
    
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:56:2d:b4  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 92  bytes 7648 (7.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 92  bytes 7648 (7.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    root@tda4vm-sk:~# cangen can1 -f -g 0
    ^Croot@tda4vm-sk:~# ifconfig
    can1: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 292141  bytes 4594600 (4.3 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 119
    
    can3: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 292141  bytes 4594600 (4.3 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 122
    
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:56:2d:b4  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 92  bytes 7648 (7.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 92  bytes 7648 (7.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    root@tda4vm-sk:~# cangen can1 -f -g 0
    ^Croot@tda4vm-sk:~# ifconfig
    can1: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 1528320  bytes 24079680 (22.9 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 119
    
    can3: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 1528320  bytes 24079680 (22.9 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 122
    
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:56:2d:b4  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 92  bytes 7648 (7.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 92  bytes 7648 (7.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    root@tda4vm-sk:~# cangen can1 -g 0
    ^Croot@tda4vm-sk:~# ifconfig
    can1: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 91340388  bytes 540513999 (515.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 119
    
    can3: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 91340388  bytes 540513999 (515.4 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 122
    
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:56:2d:b4  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 92  bytes 7648 (7.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 92  bytes 7648 (7.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    root@tda4vm-sk:~#
    
    

    Maybe the key here is using traditional CAN vs CAN FD protocol. Can you also try with cangen with the -f option to confirm if this is seen on your board as well?

    Regards,

    Takuma

  • Hi Takuma

    Looking at the bus load graph, the difference is as follows.

    The issue now is not to verify the behavior of "cangen".
    When mounted on a car, the packet does not occur the same as "cangen". It was only used as an alternative to reproduce the symptoms.
    The point of the current issue is to analyze the issue regarding the occurrence of the message "m_can_platform 2691000.can11: msg lost in rxf0".

    Regards,

    Dohyeon.

  • Hi Dohyeon,

    Can you confirm that you can get a working CAN set up with cangen where "msg lost in rxf0" is never observed, so that we can use this as a reference to debug your usecase?

    I understand that the issue is not to verify the behavior of cangen, and we are only using it as a method to debug your original usecase.

    However, because the issue can be reproduced with cangen, and furthermore, fixed by changing the behavior of cangen, I propose we investigate this difference in behavior so that you can use the learnings to fix your original usecase.

    Where I am trying to go with these experiments is that if you set the exact same settings in your PCAN tool usecase as the working cangen usecase where the "msg lost in rxf0" does not occur, then the behavior should be the exact same and issue can be fixed.

    Regards,

    Takuma

  • Hi Takuma

    I took out the CAN FD and tested it as below.

    ip link set can10 txqueuelen 1000

    ip link set can10 up type can bitrate 500000 sample-point 0.80 restart-ms 300

    ip link set can11 txqueuelen 1000

    ip link set can11 up type can bitrate 500000 sample-point 0.80 restart-ms 300

    The same problem is reproduced.

    root@vdms:~# candump -s 2 can11 &
    [1] 994
    root@vdms:~# [  190.791488] can: controller area network core
    [  190.793791] NET: Registered PF_CAN protocol family
    [  190.801248] can: raw protocol
    root@vdms:~#
    root@vdms:~# cangen can10 -g 0 &
    [2] 1005
    root@vdms:~#
    root@vdms:~# ip -d -s link show can10
    14: can10: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 300
              bitrate 500000 sample-point 0.800
              tq 12 prop-seg 63 phase-seg1 64 phase-seg2 32 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 27d1000.can
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
          11773904 2048434      0       0       0       0
    root@vdms:~# ip -d -s link show can11
    15: can11: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 300
              bitrate 500000 sample-point 0.800
              tq 12 prop-seg 63 phase-seg1 64 phase-seg2 32 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 2691000.can
        RX:  bytes packets errors dropped  missed   mcast
          11842703 2060378     69       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
    root@vdms:~# [  610.834511] m_can_platform 2691000.can can11: msg lost in rxf0
    [  610.837675] m_can_platform 2691000.can can11: msg lost in rxf0
    [  656.439162] m_can_platform 2691000.can can11: msg lost in rxf0
    [  656.443703] m_can_platform 2691000.can can11: msg lost in rxf0
    [  656.448094] m_can_platform 2691000.can can11: msg lost in rxf0
    [  656.537217] m_can_platform 2691000.can can11: msg lost in rxf0
    [  656.540685] m_can_platform 2691000.can can11: msg lost in rxf0

    Regard,

    Dohyeon

  • Hi Dohyeon, 

    Classical CAN can only support up to 1 Mbit/s, while CAN FD can go up to 5~8 Mbit/s. I saw in your original use case that CAN FD is being used, but since you are moving away from CAN FD, is your usecase actually to use classical CAN at over 1 Mbit/s?

    If not, please confirm whether the settings that I shared previously for setting CAN FD at over 1 Mbit/s causes the msg lost error on your platform. Furthermore, please use the same working settings in your PCAN program to see if the issue is fixed.

    Regards,

    Takuma

  • Hi Takuma

    When executing "cangen", an issue was raised to the "-f" option and additional tests were performed on the classic CAN.
    (I used "cangen" instead of PCAN as a packet generator.)
    The reason why we conducted the additional test is that the CAN FD setting is not the only problem, it is also a problem that occurs in classical CAN.
    It is suspected that there is a vulnerability in handling CAN packet.
    Anyway, it has been confirmed that "msg lost in rxf0" occurs in CAN FD status, so please analyze the cause and come up with improvement plan.

    Regards,

    Dohyeon

  • Hi ,

      Our customer use CAN interface as below

        500Kbps HS-CAN

        500K-2Mbps CAN FD.

      In previous your answer, you concerned CAN FD of cangen -f option.

      In fact, already we tested for 500K-2M CAN FD and 500K HS-CAN with PCAN and two port loop back.   Always the result was same as "msg lost in rxf0".

      So I ordered to DoHyeon to providing the test result for 500Kbps HS-CAN..

      Currently I'm doubt the performance or arbitration of "Interconnect" login in DRA821.

     

        Please double check in carefully for 500K CAN HS and 2M CAN FD. And let's escalate to your developer for this issue.

        I should give the feedback to OEM ASAP.

    Regards

    YoungHan Kim

  • Hi YoungHan,

    I see the errors in my post from 3 days ago. I was setting arbitration rate to 2Mbit/s, which explains why classical CAN would fail, since 1Mbit/s is max for classical CAN. Therefore, so far, on TI EVM, we cannot reproduce the issue unless we intentionally run classical CAN at over specifications.

    I tried with 500Kbit/s arbitration rate with sender configured as classical CAN at 500Kbit/s, and receiver as CAN FD with 500Kbit/s arbitration rate and 2Mbit/s data bit rate and could not reproduce the msg lost error.

    However, I do see Dohyeon's logs, so I am sure you are seeing an issue. But, as of now, we are unable to reproduce the issue on TI EVM.

    Does Dohyeon or you have a TI EVM to see if you can reproduce the issue? If the issue cannot be reproduced on TI EVM, then issue may not be with software.

    Regards,

    Takuma

  • Hi Takuma,

      You seems not reproduce the our issue in EVM.

      Currently we tested with our custom board with DRA821 SoC.

      We have TI's DRA821 EVM and TI's DRA829 EVM.

      Ok! We will accept your suggestion to double check with TI EVM in our side.

      Already we spent a lot of time for this issue. Really I want sync in both side in this time.

      We are not familiar than your for EVM.  So please inform in detail to reproduce in our side with TI's EVM.

        1. EVM name

        2. S/W for EVM (which version of prebuit image is used? if used additional patch binary, please inform to us in detail)

        3. Jumper configuration in EVM

        4. CAN interface loop connection in EVM (please provide in picture)

        5. linux command to reproduce in our side.

        6. Test result screen shot in your side

      Please answer for above information within today!

      Thanks!

    Regards

    YoungHan Kim

      

  • Hi YoungHan,

    I used the J7200 EVM + CPB board: https://www.ti.com/tool/J7200XSOMXEVM

    S/W is 9.2 Linux SDK, since 9.1 by default does not have the MCAN in device tree: https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-J7200

    I connected MCU_MCAN0 and MCU_MCAN1.

    I can send you the picture tomorrow when I get back in the lab, complete with Linux command and test result.

    Regards,

    Takuma

  • Hi YoungHan,

    I would need one more day to send you a picture, since my J7200 board is currently being borrowed by a different member. However, J30 and J31 should be the headers to connect.

    Regards,

    Takuma

  • Hi Takuma

    Isn't the data ready yet?

    Please share the progress.

    Regards,

    Dohyeon

  • Hi Dohyeon and YoungHan,

    Apologies for the delay. Just got my board back from the labs today. Attached below are my logs complete with the commands used to run the test:

    j7200-evm login: root
    [ 1068.894918] audit: type=1006 audit(1651168812.016:10): pid=1011 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=3 res=1
    [ 1068.907849] audit: type=1300 audit(1651168812.016:10): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=fffff583b448 a2=1 a3=ffff9f025020 items=0 ppid=1 pid=101       1 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
    [ 1068.934657] audit: type=1327 audit(1651168812.016:10): proctitle="(systemd)"
    [ 1068.942078] audit: type=1334 audit(1651168812.032:11): prog-id=11 op=LOAD
    [ 1068.949365] audit: type=1300 audit(1651168812.032:11): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=ffffd12fb900 a2=78 a3=0 items=0 ppid=1 pid=1011 auid=0        uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)
    [ 1068.975191] audit: type=1327 audit(1651168812.032:11): proctitle="(systemd)"
    [ 1068.982589] audit: type=1334 audit(1651168812.056:12): prog-id=11 op=UNLOAD
    [ 1068.989849] audit: type=1334 audit(1651168812.056:13): prog-id=12 op=LOAD
    [ 1068.997018] audit: type=1300 audit(1651168812.056:13): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=ffffd12fb9a0 a2=78 a3=0 items=0 ppid=1 pid=1011 auid=0        uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)
    [ 1069.022667] audit: type=1327 audit(1651168812.056:13): proctitle="(systemd)"
    root@j7200-evm:~# ifconfig -a
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:59:e3:b0  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 92  bytes 7648 (7.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 92  bytes 7648 (7.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    main_mcan0: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 255
    
    main_mcan3: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 2
    
    mcu_mcan0: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    mcu_mcan1: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 1
    
    root@j7200-evm:~# ip link set mcu_mcan0 type can bitrate 500000 dbitrate 2000000 berr-reporting on fd on
    root@j7200-evm:~# ip link set mcu_mcan1 type can bitrate 500000 berr-reporting on
    root@j7200-evm:~# ip link set up mcu_mcan0
    [ 1252.882699] IPv6: ADDRCONF(NETDEV_CHANGE): mcu_mcan0: link becomes ready
    root@j7200-evm:~# ip link set up mcu_mcan1
    [ 1253.894439] IPv6: ADDRCONF(NETDEV_CHANGE): mcu_mcan1: link becomes ready
    root@j7200-evm:~# ip link set mcu_mcan0 txqueuelen 1000
    root@j7200-evm:~# ip link set mcu_mcan1 txqueuelen 1000
    root@j7200-evm:~# candump -s 2 mcu_mcan0 &
    [1] 1036
    root@j7200-evm:~# [ 1263.218920] can: controller area network core
    [ 1263.223350] NET: Registered PF_CAN protocol family
    [ 1263.235399] can: raw protocol
    cangen mcu_mcan1 -g 0
    ^Croot@j7200-evm:~# ip -d -s link show mcu_mcan1
    5: mcu_mcan1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
              bitrate 500000 sample-point 0.875
              tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 40568000.can
        RX:  bytes packets errors dropped  missed   mcast
                 0       0      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
          46797655 8138309      0       0       0       0
    root@j7200-evm:~#
    root@j7200-evm:~# ip -d -s link show mcu_mcan0
    4: mcu_mcan0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
              bitrate 500000 sample-point 0.875
              tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              dbitrate 2000000 dsample-point 0.750
              dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 dbrp 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 40528000.can
        RX:  bytes packets errors dropped  missed   mcast
          46797655 8138309      0       0       0       0
        TX:  bytes packets errors dropped carrier collsns
                 0       0      0       0       0       0
    root@j7200-evm:~#
    
    

    Essentially, I configure mcu_mcan0 as CAN-FD with dbitrate of 2Mb/s and arbitration bitrate as 500Mb/s, and use it as a receiver. On the other hand, mcu_mcan1 is configured as a classical MCAN interface with bitrate of 500Mb/s and used as a sender.

    I've let it run some time, but no dropped packets yet.

    Lastly, connection looks like below. Just some jumper wires between J30 and J31.

    Regards,

    Takuma

  • Hi Takuma

    We use the main can interface.
    Please test using main_can0 and main_can2 in EVM

    Regards,

    Dohyeon

  • Hi Dohyeon,

    J7200 EVM is slightly strange for main CAN interface, so took some time... but I was able to do the same experiment with similar results (although, I did find an interesting thing that may or may not affect your board):

    1. main_mcan3 has issues due to mux-controller having the same name in dts file. Can be fixed with this patch:https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_fixing_2D00_main_5F00_mcan3.patch
      However, issue is board specific and the error log is "m_can_platform 2731000.can main_mcan3: bus-off", which is different from how your board is failing
    2. main_mcan0 is routed to the SOM board instead of CPB board, so had to connect like below for main_mcan0 <-> main_mcan3 test:

    However, after those two learnings I do not see any errors. Logs below for reference:

    j7200-evm login: root
    [   60.492434] audit: type=1006 audit(1651182077.988:10): pid=994 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=3 res=1
    [   60.505178] audit: type=1300 audit(1651182077.988:10): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=ffffd50c1938 a2=1 a3=ffff9a67c020 items=0 ppid=1 pid=994 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
    [   60.531833] audit: type=1327 audit(1651182077.988:10): proctitle="(systemd)"
    [   60.539210] audit: type=1334 audit(1651182078.000:11): prog-id=11 op=LOAD
    [   60.546460] audit: type=1300 audit(1651182078.000:11): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=ffffe26a1500 a2=78 a3=0 items=0 ppid=1 pid=994 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)
    [   60.572167] audit: type=1327 audit(1651182078.000:11): proctitle="(systemd)"
    [   60.579591] audit: type=1334 audit(1651182078.028:12): prog-id=11 op=UNLOAD
    [   60.586868] audit: type=1334 audit(1651182078.028:13): prog-id=12 op=LOAD
    [   60.594013] audit: type=1300 audit(1651182078.028:13): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=ffffe26a15a0 a2=78 a3=0 items=0 ppid=1 pid=994 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)
    [   60.619522] audit: type=1327 audit(1651182078.028:13): proctitle="(systemd)"
    root@j7200-evm:~#
    root@j7200-evm:~# ls
    root@j7200-evm:~# ifconfig -a
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:59:e3:b0  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 94  bytes 7766 (7.5 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 94  bytes 7766 (7.5 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    main_mcan0: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 255
    
    main_mcan3: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    mcu_mcan0: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 1
    
    mcu_mcan1: flags=128<NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 2
    
    root@j7200-evm:~# ip link set main_mcan0 type can bitrate 500000 dbitrate 2000000 berr-reporting on fd on
    root@j7200-evm:~# ip link set main_mcan3 type can bitrate 500000 berr-reporting on
    root@j7200-evm:~# ip link set up main_mcan0
    [   76.530325] IPv6: ADDRCONF(NETDEV_CHANGE): main_mcan0: link becomes ready
    root@j7200-evm:~# ip link set up main_mcan3
    root@j7200-evm:~# [   77.547427] IPv6: ADDRCONF(NETDEV_CHANGE): main_mcan3: link becomes ready
    ip link set main_mcan0 txqueuelen 1000
    root@j7200-evm:~# ip link set main_mcan3 txqueuelen 1000
    root@j7200-evm:~# candump main_mcan0 &
    [1] 1019
    root@j7200-evm:~# [   91.028123] can: controller area network core
    [   91.033451] NET: Registered PF_CAN protocol family
    [   91.046146] can: raw protocol
    
    root@j7200-evm:~# cansend main_mcan1 123#112233
    if_nametoindex: No such device
    root@j7200-evm:~# cansend main_mcan3 123#112233
      main_mcan0  123   [3]  11 22 33
    root@j7200-evm:~# cansend main_mcan3 123#112233
      main_mcan0  123   [3]  11 22 33
    root@j7200-evm:~# cansend main_mcan3 123#112233
      main_mcan0  123   [3]  11 22 33
    root@j7200-evm:~# cansend main_mcan3 123#112233
      main_mcan0  123   [3]  11 22 33
    root@j7200-evm:~# cansend main_mcan3 123#112233
      main_mcan0  123   [3]  11 22 33
    root@j7200-evm:~# cansend main_mcan3 123#112233
      main_mcan0  123   [3]  11 22 33
    root@j7200-evm:~# ifconfig
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 34:08:e1:59:e3:b0  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 94  bytes 7766 (7.5 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 94  bytes 7766 (7.5 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    main_mcan0: flags=193<UP,RUNNING,NOARP>  mtu 72
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 6  bytes 18 (18.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 255
    
    main_mcan3: flags=193<UP,RUNNING,NOARP>  mtu 16
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 6  bytes 18 (18.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    root@j7200-evm:~# ps aux | grep can
    root         397  0.0  0.0   2708  1396 ?        Ss   21:40   0:00 /usr/sbin/tee-supplicant
    root         408  0.0  0.0      0     0 ?        I<   21:40   0:00 [optee_bus_scan]
    root        1019  0.0  0.0   2200   772 ttyS2    S    21:41   0:00 candump main_mcan0
    root        1034  0.0  0.0   3100   872 ttyS2    S+   21:42   0:00 grep can
    root@j7200-evm:~# kill 1019
    root@j7200-evm:~#
    [1]+  Done                    candump main_mcan0
    root@j7200-evm:~#
    root@j7200-evm:~# candump -s 2 main_mcan0 &
    [1] 1035
    root@j7200-evm:~# cangen main_mcan3 -g 0
    ^Croot@j7200-evm:~# ip -d -s link show main_mcan0
    3: main_mcan0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
              bitrate 500000 sample-point 0.875
              tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              dbitrate 2000000 dsample-point 0.750
              dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 dbrp 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 2701000.can
        RX:  bytes  packets errors dropped  missed   mcast
         109610630 19062182      0       0       0       0
        TX:  bytes  packets errors dropped carrier collsns
                 0        0      0       0       0       0
    root@j7200-evm:~# ip -d -s link show main_mcan3
    4: main_mcan3: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
        link/can  promiscuity 0 minmtu 0 maxmtu 0
        can <BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
              bitrate 500000 sample-point 0.875
              tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1 brp 1
              m_can: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
              m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp_inc 1
              clock 80000000
              re-started bus-errors arbit-lost error-warn error-pass bus-off
              0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 2731000.can
        RX:  bytes  packets errors dropped  missed   mcast
                 0        0      0       0       0       0
        TX:  bytes  packets errors dropped carrier collsns
         109610630 19062182      0       0       0       0
    root@j7200-evm:~#
    
    

    As a possibility, if the TI EVM reference design and device tree were followed, then it could be possible for #1 to cause issues on your custom board. If #1 is not applicable, then issue looks to be specific to your custom board.

    Regards,

    Takuma

  • Hi Takuma

    How can I apply the attached patch file on the yocto system?

    Regards,

    Dohyeon

  • Hi Dohyeon,

    If using the Linux SDK, there should be the Linux kernel source files installed under board-support/ti-linux-kernel-*. The patch can be applied to the source file and built+installed using the Top-Level Makefile as documented here: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/09_02_00_05/exports/docs/linux/Overview_Top_Level_Makefile.html 

    Regards,

    Takuma

  • Hi Takuma

    When we did the same test on EVMs we have, "m_can_platform 2701000.can0: msg lost in rxf0" log did not occur.
    Compared to Dasan-designed boards, DRA821 chip part-number is different.

    DASAN     
    EVM    

    In the case of Dasan-designed boards, when scaling_governor was set to performance, packet drop did not occur.

    Q1. Is there a difference between the CPU on EVMs and the CPU on Dasan designed boards?

    Q2. How does it affect internal behavior when setting scaling_governor to performance?

    Q3. Is there anything I should check if I set scaling_governor to performance on a regular basis?

    Regards,

    Dohyeon.

  • Hi Dohyeon,

    Good find on the scaling_governor. As for your questions:

    Q1. Is there a difference between the CPU on EVMs and the CPU on Dasan designed boards?

    Yes, there might be some differences, but I think scaling_governor will cause the most difference

    Q2. How does it affect internal behavior when setting scaling_governor to performance?

    Scaling_governor affects dynamic frequency scaling of the ARM A72 cores. When set to performance (which should be default for our SDK for DRA821), then it sets the A72 core to run at max frequency at 2GHz. If it is not set to performance, then it will have different behavior based on this kernel documentation: https://docs.kernel.org/admin-guide/pm/cpufreq.html#generic-scaling-governors

    Q3. Is there anything I should check if I set scaling_governor to performance on a regular basis?

    Power consumption and heat may be affected, but other than that, you should see stability improvements since frequency will not dynamically change and you will get the best performance of the SoC.

    If power consumption and heat are tolerable with scaling_governor set to performance, then I would recommend going with that as the default.

    Regards,

    Takuma