CAN Bus "Bus-Off" Error on Apalis i.MX8 with TDX Multimedia Reference Image

Hello,

I am working with the Apalis i.MX8 8GB 32GB V1.1A on the Apalis Evaluation Board V1.1Z, using the Toradex Multimedia Reference Image. While setting up CAN bus communication, I’m encountering a “bus-off” error after attempting to send a CAN message. Below are the detailed steps and output:

  • Apalis iMX8 QuadMax 8GB Wi-Fi / Bluetooth IT
  • Apalis Evaluation Board V1.1Z
  • Apalis-iMX8_Reference-Multimedia-Image 6.7.0

PN: 0067

Setup and Configuration:

root@apalis-imx8-15310003:~# ip link set can0 up type can bitrate 250000
[ 2179.664285] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

CAN0 Interface Details:

root@apalis-imx8-15310003:~# ip -details link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
          bitrate 250000 sample-point 0.875
          tq 50 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 2
          flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
          flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
          clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 5a8d0000.can

Sending a CAN Message:

root@apalis-imx8-15310003:~# cansend can0 123#DEADBEEF

Error Encountered:

[ 2201.068954] flexcan 5a8d0000.can can0: bus-off

CAN0 Interface Details After Error:

root@apalis-imx8-15310003:~# ip -details link show can0
3: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state BUS-OFF (berr-counter tx 0 rx 0) restart-ms 0 
          bitrate 250000 sample-point 0.875
          tq 50 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1 brp 2
          flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp_inc 1
          flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp_inc 1
          clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform parentdev 5a8d0000.can

As seen, after sending the CAN message, the interface goes into a “bus-off” state. I have checked the bitrate, and everything seems to be set up correctly.

Request for Assistance:

  • Is there something I am missing in the configuration?
  • Has anyone encountered similar issues, and how can I resolve this “bus-off” error?

Any guidance would be appreciated.

Thank you!

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


The “bus-off” error in CAN communication typically indicates that the CAN controller has detected too many errors on the bus and has transitioned into a state where it stops transmitting messages. Here are a few steps and considerations to help resolve this issue:

  1. Check Physical Connections: Ensure that the CAN bus is properly terminated with 120-ohm resistors at both ends. Poor termination can lead to reflections and errors on the bus.

  2. Bitrate Matching: Double-check that all devices on the CAN bus are configured to use the same bitrate. A mismatch in bitrate can cause communication errors leading to a bus-off state.

  3. Cable Length and Quality: Verify that the cable length is within the acceptable range for the bitrate being used. Also, ensure that the cable quality is suitable for CAN communication.

  4. Error Counters: Monitor the error counters (tx and rx) to see if they provide any clues about the source of the errors. High error counts can indicate issues with the physical layer or configuration.

  5. Isolation: If possible, isolate the Apalis iMX8 and the Apalis Evaluation Board from other devices on the CAN bus to determine if the issue persists. This can help identify if another device is causing the problem.

  6. Software Configuration: Ensure that the CAN interface is correctly configured in the software. Double-check the settings for sample point, propagation segment, and phase segments.

  7. Restart CAN Interface: After a bus-off state, the CAN interface needs to be restarted. This can be done by bringing the interface down and then up again:

    ip link set can0 down
    ip link set can0 up type can bitrate 250000
    
  8. Check for Known Issues: Review the errata and known issues for the Apalis iMX8 to see if there are any documented problems related to CAN communication.

If the issue persists after these checks, it may be beneficial to reach out to Toradex technical support for further assistance, as they can provide more specific guidance based on the hardware and software configuration.

Please, also check if these links can help you solve your problem:

CAN packets dropped if high bus load on Apalis iMX8 Boot2Qt image and working GUI.

Hi @wissemyakoubi!

Have you tested/checked the tips present in Toradex AI’s message above?

Best regards,

Hi @henrique.tx

Thanks for the suggestions! I have checked and tested all the tips you mentioned, but unfortunately, I’m still encountering the same error. Do you have any additional insights or steps I could try?
I tested also with Ixora carrier board V1.3A , it is also the same problem.

Best regards,

Hi @wissemyakoubi !

I just tested on my side. Here is the setup I did to communicate between 2 Apalis on Ixora.

TL;DR: it worked.

Apalis iMX6

Hardware

  • Apalis iMX6D 512MB V1.1B
  • Ixora V1.1B

Software

  • Toradex Reference Minimal Image from BSP 6.8.0 (upstream-based)

Apalis iMX8

Hardware

  • Apalis iMX8QM 4GB WB/IT V1.1C
  • Ixora V1.2B

Software

  • Toradex Reference Minimal Image from BSP 6.8.0 (downstream-based)

CAN bus connection

I connected both X20.1 and X20.2 together, as can be seen in the picture below

Device tree configuration

Device tree

By default, the device tree of Apalis Evaluation Board is loaded. As I am using Ixora, I changed it on both. I had to connect to each serial console, stop on U-Boot and modify the fdtfile U-Boot environment variable.

Apalis iMX6

setenv fdtfile imx6q-apalis-ixora-v1.1.dtb # set the correct device tree for the carrier board
saveenv # make it persistent
reset # reboot

Apalis iMX8

setenv fdtfile imx8qm-apalis-v1.1-ixora-v1.2.dtb # set the correct device tree for the carrier board
saveenv # make it persistent
reset # reboot

CAN bus configuration

On both modules, I had to configure the CAN interface accordingly. First, checking if they are available:

root@apalis-imx6-10692081:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
3: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
4: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:14:2d:a3:25:f1 brd ff:ff:ff:ff:ff:ff
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
6: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 3a:dc:58:b7:5b:d7 brd ff:ff:ff:ff:ff:ff

Now, configuring them (please note that the message can0: link becomes ready will only show up via serial console and not via SSH) :

root@apalis-imx8-06980209:~# ip link set can0 up type can bitrate 250000
[   63.422543] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@apalis-imx6-10692081:~# ip link set up can0 type can bitrate 250000
root@apalis-imx6-10692081:~#

Sending messages

Then I can finally send the CAN messages between both modules.

root@apalis-imx6-10692081:~# cansend can0 123#45.67.89
root@apalis-imx6-10692081:~# cansend can0 123#45.67.89
root@apalis-imx6-10692081:~# cansend can0 123#45.67.00
root@apalis-imx6-10692081:~# cansend can0 123#45.ff
root@apalis-imx6-10692081:~#
root@apalis-imx8-06980209:~# candump can0
[  190.413278] can: controller area network core
[  190.417786] NET: Registered PF_CAN protocol family
[  190.428737] can: raw protocol
  can0  123   [3]  45 67 89
  can0  123   [3]  45 67 89
  can0  123   [3]  45 67 00
  can0  123   [2]  45 FF

And it works both ways.


Since you are using Apalis Evaluation Board, could you please double check the jumper configuration you have on your carrier board? Please check the section CAN 3.13.1.1 (page 39). Specifically the table with the jumper JP15, JP16, JP17 and JP18. Please also double check if you are using the right pins from the connectors at X32 top and/or bottom.

Also, could you please send a picture of your physical connection? It can help us to find the possible issue.

Best regards,

Hi @henrique.tx,

I followed the same guide using the Ixora carrier board V1.3A with Apalis i.MX8 8GB 32GB V1.1A, but the “bus off” issue persists as shown in the screenshots below:

When I checked the schematics of the Ixora V1.3A, I noticed that it is different from versions 1.1 and 1.2. There are CAN standby and silent pins, as shown below:


Are there any changes needed in the device tree to make it work?

I also tested with the Apalis evaluation board V1.1Z.

Hi @wissemyakoubi !

To use can on the carrier boards, only their device tree are needed:

  • Apalis iMX8 v1.1 & Ixora v1.3 → imx8qm-apalis-v1.1-ixora-v1.2.dtb
  • Apalis iMX8 v1.1 & Apalis Evaluation Board → imx8qm-apalis-v1.1-eval.dtb

I just tested an Apalis iMX8QM 4GB WB V1.0B (with Reference Minimal Image from BSP 6.8.0) on an Ixora V1.3A communicating with a Verdin AM62 Q 2GB WB IT (with Torizon OS 7.0.0) on a Dahlia V1.1C and it works as expected.

Could you please share more details about what/how you connected the devices you are communicating? Or are you doing loopback test on only one CAN interface?

Best regards,

hi @henrique.tx !

I am currently using a PeakCan USB device to test sending and receiving CAN frames from my Apalis iMX8 setup. Below are some details of my setup with the Apalis Evaluation Board (pictures are attached for reference):


The device tree setup is correct, as you mentioned. I’m using the following device tree:

When I attempt to send CAN frames from the Apalis iMX8, here’s the output I get:

Also, when I connect the PeakCan USB device and try to use candump, I’m not receiving any frames from the PeakCan:

I’ve tested it in loopback mode, and it works perfectly.

As for the connection, I’m not doing a loopback test now. The devices are connected through the PeakCan USB device for actual communication. I’m happy to provide more details if needed.

Hi @wissemyakoubi !

Besides loopback mode, have you tried to communicate between both CAN interfaces of the module? (between can0 and can1)
If this also works, then the issue might be on PeakCan’s side.

Best regards,

HI @henrique.tx !

I’ve tested the communication between can0 and can1, but the same error persists. Here’s the output from the serial terminal:

apalis-imx8-15310003 login: root
[   21.162808] audit: type=1334 audit(1729788235.408:8): prog-id=11 op=LOAD
[   21.169896] audit: type=1334 audit(1729788235.416:9): prog-id=12 op=LOAD
[   21.443837] audit: type=1006 audit(1729788235.692:10): pid=812 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=1 res=1
[   21.456300] audit: type=1300 audit(1729788235.692:10): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=fffff263af90 a2=1 a3=ffffa3a12020 items=0 ppid=1 pid=812 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
[   21.482887] audit: type=1327 audit(1729788235.692:10): proctitle="(systemd)"
[   21.490054] audit: type=1334 audit(1729788235.732:11): prog-id=13 op=LOAD
[   21.496916] audit: type=1300 audit(1729788235.732:11): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=ffffec602cc0 a2=78 a3=0 items=0 ppid=1 pid=812 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="systemd" exe="/lib/systemd/systemd" key=(null)
[   21.522468] audit: type=1327 audit(1729788235.732:11): proctitle="(systemd)"
[   21.529651] audit: type=1334 audit(1729788235.736:12): prog-id=13 op=UNLOAD
[   21.536744] audit: type=1334 audit(1729788235.736:13): prog-id=14 op=LOAD
root@apalis-imx8-15310003:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:14:2d:e9:9c:b3 brd ff:ff:ff:ff:ff:ff
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
5: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 0e:5f:cc:82:0f:16 brd ff:ff:ff:ff:ff:ff
6: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether e8:fb:1c:ce:01:35 brd ff:ff:ff:ff:ff:ff
7: uap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether e8:fb:1c:ce:03:35 brd ff:ff:ff:ff:ff:ff
root@apalis-imx8-15310003:~# [   40.111537] kauditd_printk_skb: 3 callbacks suppressed
[   40.111555] audit: type=1334 audit(1729788254.360:15): prog-id=10 op=UNLOAD
[   40.123787] audit: type=1334 audit(1729788254.360:16): prog-id=9 op=UNLOAD
ip link set can0 up type can bitrate 250000
[   42.552258] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@apalis-imx8-15310003:~# ip link set can1 up type can bitrate 250000
[   48.471673] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
root@apalis-imx8-15310003:~# candump
candump            candump.can-utils
root@apalis-imx8-15310003:~# candump can0 &
root@apalis-imx8-15310003:~# [   69.087762] can: controller area network core
[   69.092271] NET: Registered PF_CAN protocol family
[   69.104337] can: raw protocol

root@apalis-imx8-15310003:~# cansend can1 123#45.ff
root@apalis-imx8-15310003:~# [   83.291272] flexcan 5a8e0000.can can1: bus-off

Note: I used the Reference Minimal Image from BSP 6.8.0 for this test.

Another important observation: I noticed that the fan isn’t operating as expected. After investigating, I found that GPIO8 (power enable for the fan) only works when I connect it directly to the 3.3V supply. It appears to be mapped to /dev/gpiochip3, line 28, under control of the GPIO fan driver. I also tested GPIOs 2, 3, 5, 6, and 7 with gpiolib. When setting them high, the output remains low, and gpiomon does not detect any state change between GND and 3.3V.

Could this indicate a hardware issue with the Apalis module?

Hi @wissemyakoubi !

Thanks for the test results.

This is strange… We do such tests ourselves and it works:

Would you be able to test another Apalis iMX8QM module? Do you see the same issues on another Apalis iMX8QM module?

Best regards,

Hi @henrique.tx !

Thank you for the response and for sharing the test results.

Unfortunately, I only have access to one Apalis iMX8QM module at the moment, so I’m unable to test with another module to compare results.

Let me know if there are any specific troubleshooting steps I can try on this module to help isolate the issue.

Best regards

Hello @wissemyakoubi,

In order to rule out hardware issues, can you do the following test?

Hardware:

  • Apalis iMX8
  • Ixora Carrier Board
  • Cooler Installed
  • Board connected to local network (for SSH)
  • CAN connected for Loopback, as you can see in the following picture:

Please note the wire color in the picture above, CAN_L is on pins 6 and 1 while CAN_H is on pins 2 and 5.

Software:

  • Fresh installation of the Toradex Reference Multimedia Image 6.7.0

Procedure:

  1. Connect to the board via serial port or ssh
  2. Set the correct device tree for Ixora:
fw_setenv fdtfile imx8qp-apalis-v1.1-ixora-v1.2.dtb
  1. Restart the board:
reboot now
  1. Confirm that both CAN0 and CAN1 are available:
ip link show
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
      link/ether 00:14:2d:67:d5:77 brd ff:ff:ff:ff:ff:ff
  3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
      link/can 
  4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
      link/can 
  5: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
      link/ether d8:c0:a6:cf:78:dd brd ff:ff:ff:ff:ff:ff
  6: uap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
      link/ether d8:c0:a6:cf:7a:dd brd ff:ff:ff:ff:ff:ff
  7: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
      link/ether 7e:c6:29:21:be:76 brd ff:ff:ff:ff:ff:ff
  1. Configure CAN0 and CAN1:
ip link set can0 up type can bitrate 250000
ip link set can1 up type can bitrate 250000
  1. Confirm that both CAN0 and CAN1 are up:
ip link show
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
      link/ether 00:14:2d:67:d5:77 brd ff:ff:ff:ff:ff:ff
  3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
      link/can 
  4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
      link/can 
  5: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
      link/ether d8:c0:a6:cf:78:dd brd ff:ff:ff:ff:ff:ff
  6: uap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
      link/ether d8:c0:a6:cf:7a:dd brd ff:ff:ff:ff:ff:ff
  7: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
      link/ether 7e:c6:29:21:be:76 brd ff:ff:ff:ff:ff:ff
  1. Monitor CAN1:
candump can1
  1. Open a second terminal via SSH
  2. On the second terminal, send messages on CAN0:
cansend can0 123#01020304

Now, on the first terminal you should see the following:

candump can1
  can1  123   [4]  01 02 03 04

This or other messages can be sent multiple times, without a drop in the CAN interface.

Please let me know if this works for you, if not we may have a hardware issue.

Best Regards,
Bruno

Hello @wissemyakoubi,

Were you able to test the setup above?
If yes, did it work for you?

Best Regards,
Bruno

Hi @bruno.tx ,

I test it but the same error still showing bus off :((

Hello @wissemyakoubi,

Do you have either another Apalis iMX8 module or another Ixora Carrier board to test this on?
I want to understand where the problem may be here, as it is possible that the issue is in the Carrier Board or the Module.

Best Regards,
Bruno

Hello @bruno.tx
I think that the problem is in the module , because i test it with apalis developpement board and the same error shows up
Best regards,

Hello @wissemyakoubi,

That would make sense, but it would be important to test this if possible.
Do you have any way to test this by using another module or Ixora Board?

If you conclude that this problem is indeed present in the module itself, please submit an RMA request via the following link: Return Material Authorization (RMA)

Best Regards,
Bruno

Hello @wissemyakoubi,

Did you do additional tests with this module?
Is the problem still present?

Best Regards,
Bruno