BBB CAN TX only works at loop-situation

Hi!

I’m working on BeagleBone Black board to confirm the CAN communication between the BBB and another device.

As I check the BBB with ifconfig command & oscilloscope, I could see that BBB does transmit the can data when “loopback on” at ip link setting.

But when that loopback mode is off, it seems BBB does not transmit the can data because ifconfig shows zero tx count increase and I cannot see any signal at tx jumper cable with oscilloscope device.

+) “cat /proc/net/can/stats” command displays ‘transmitted frames’ increasing whether or not the ‘loopback’ option is on.

My BBB is updated to the latest image. Any help would be very welcome. Thank you.

+) Additional info

  • SocketCAN library is installed and I have been using cansend.

  • The ‘sudo apt-get update and upgrade’ were recently done.

  • I’m not using physical capes for BBB,
    but using CAN Bus transceiver like in the middle of this link page:
    Adding CAN to the BeagleBone (Black) – Beyondlogic

  • BBB did succeed in receiving can data with same set up.
    But only TX from BBB shows no signal, even before it reaches the CAN bus transceiver.
    BBB pin 26 (for can1) shows no tx signal, checked with oscilloscope.
    But, it does show signal and works when using ‘loopback’ mode is on.

*terminal display of ‘loopback’ on/off and tx count

root@beaglebone:/# ifconfig can1
can1: 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 10  (UNSPEC)
        RX packets 8  bytes 60 (60.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 12 (12.0 B)
        TX errors 0  dropped 2 overruns 0  carrier 2  collisions 0
        device interrupt 43

root@beaglebone:/# sudo ip link set can1 down
root@beaglebone:/# sudo ip link set can1 up type can bitrate 250000 loopback on
root@beaglebone:/# sudo cansend can1 000#00.01.02.03.04.05.06.07
root@beaglebone:/# ifconfig can1
can1: 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 10  (UNSPEC)
        RX packets 9  bytes 68 (68.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 20 (20.0 B)
        TX errors 0  dropped 2 overruns 0  carrier 2  collisions 0
        device interrupt 43

root@beaglebone:/# sudo ip link set can1 down
root@beaglebone:/# sudo ip link set can1 up type can bitrate 250000 loopback off
root@beaglebone:/# sudo cansend can1 000#00.01.02.03.04.05.06.07
root@beaglebone:/# ifconfig can1
can1: flags=129<UP,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 12  bytes 92 (92.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 20 (20.0 B)
        TX errors 0  dropped 2 overruns 0  carrier 2  collisions 0
        device interrupt 43
  • /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
 
uname_r=4.19.94-ti-r42
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-CAN0-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-CAN1-00A0.dtbo
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###      
###Cape Universal Enable 
enable_uboot_cape_universal=1
###          
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1 
### 
###U-Boot fdt tweaks... (60000 = 384KB) 
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###
    
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet

First. You do have a CAN bus driver connected to the BBB pins correct?
Next IIRC, only can1 is easily accessible while can0 shares with HDMI I think. Not sure.

Best thing to do is to install the socketCAN library if it’s not already installed.
SocketCAN Link

Blockquote
debian@ebb:~$ sudo ip link set can1 up type can bitrate 250000
debian@ebb:~$ candump can1
can1 298 [7] 00 00 0B 00 01 00 00
can1 718 [1] 05
can1 298 [7] 00 00 0B 00 01 00 00
can1 298 [7] 00 00 0B 00 01 00 00
debian@ebb:~$

It should be that easy.

Beware of capes that only provide two wires for CAN. They must have the Beagle ground pin also connected between units to avoid common mode errors. The reason you see so many CAN dongles now with only 2 pins is because they are targeted at the automotive market where the module is powered from the same 12V battery as the other CAN devices so share a common ground.

If the above doesn’t work perhaps post more about your setup.
John
Oh and this is what I’m using.
Discontinued CAN,RS485 Cape
Cape Info

Thank you for your answer!
I added some information as you mentioned & required.

I also believe that this should be a simple problem…
I welcome any of your additional request for more set-up info.

My ifconfig shows that I’m sending data.

debian@ebb:~$ ifconfig
can1: 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 10  (UNSPEC)
        RX packets 512895  bytes 2564475 (2.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 4 (4.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 43

If I then send a CANopen Heatbeat message

debian@ebb:~$ cansend can1 705#05
debian@ebb:~$ ifconfig
can1: 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 10  (UNSPEC)
        RX packets 513035  bytes 2565173 (2.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4  bytes 5 (5.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 43

You can see the packet and byte count have increased by 1 each.

Here’s my uEnv.txt. As I have a cape with an EEROM it may well be there’s something going on in the background that I do not know about. Ever since they got rid of $SLOTS I’ve found the BBB I/O very confusing.

debian@ebb:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.19.94-ti-r68
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
#dtb_overlay=/lib/firmware/BB-W1-P8.11-00A0.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_rproc (4.14.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e

#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

The link you posted doesn’t specifically mention Beyond Logic (At least I couldn’t find it). Also if I disconnect the external CAN bus from the Beagle Cape and issue a cansend the ifconfig count does not go up. I would imagine if I put a scope on the CAN bus then at that point I’d see the continuous send of the message by the CAN hardware waiting indefinitely for the ACK from the mandatory second node.

It’s also possible the driver sees an incorrect level on the bus with nothing connected and doesn’t even try to send. You mentioned you can receive data. What are you using to send to the BBB?

First of all, I truly appreciate your efforts.

This image below is the CAN test setting of mine.

setting

(sorry for messy jumper cables)

It is between BBB and an On Board Computer, which is specifically designed for my project.
Meanwhile, the OBC uses “Atmel-11054-32-bit-ARM926EJ-S-Microcontroller-SAM9X25” MPU in it.

As you can see, BBB(red one, industrial version) pins are connected to CAN transceiver(CJMCU-230) on the left side of breadboard. Sequentially from the top, it is written 3V3, GND, CTX, CRX, CANH, CANL. Those CANH and CANL comes from the OBC cables, and there are 120 ohm resistor connected between two. The red taped one from the OBC is CANL cable, whereas the black taped one is CANH cable.

The OBC Board is powered with 3.3V, and the transceiver is also made for 3.3V.

I thought this could be due to the difference between CAN2.0A/B,
but this is not sure for now because it seems OBC is set to be CAN2.0B already. (BBB: CAN2.0B)

Now what I suspect is…

  • BBB settings for boot, cape, … is not suitable for the OBC product.
  • the CAN bus is somehow incorrectly working. (How BBB does receive can data)

Thank you!

VP230

Trace pin 8 of the SN65HVD230 (marked VP230) on your little CAN driver board. Make sure it matches the part description above. Pin 8 Rs must be connected to ground or through a resistor to ground. It looks like there is a resistor there to Vcc which has the device in sleep mode and it won’t drive the bus.

See the entire data sheet here:
CAN Driver Data sheet

I have some of the 3.3V surface mount chips in stock here. If I have a chance I’ll breadboard that to demonstrate how it works. No point in waiting 14 weeks (or never) for the AliExpress one at $2.00 and really don’t want to pay Amazon.ca $16 and wait until mid December.

Here’s the output from the Lawicel CANUSB showing a standard ID=123, DLC=8 and the data is 11 22 … 88
t12381122334455667788

So it’s possible to transmit with the Beagle wired up to a SN65HVD231 with pin 8 tied to ground. However, a key thing is that you must also set up the overlay. Without that I was not able to get anything sent. The cape I was using has EEROM so it identifies the overlay required and it’s all done in the background.

In the /boot/uEnv.txt file you have to have this line.
uboot_overlay_addr5=/lib/firmware/BB-CAN1-00A0.dtbo
After I saved and exited I then rebooted and here’s the text from the terminal session. Notice candump works as does cansend which is that message I logged with the CANUSB.

debian@ebb:~$ sudo ip link set can1 up type can bitrate 250000
[sudo] password for debian: 
debian@ebb:~$ sudo ifconfig
can1: 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 10  (UNSPEC)
        RX packets 19  bytes 97 (97.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 43  

I removed the rest of ifconfig since it’s not important.

debian@ebb:~$ sudo candump can1
  can1  298   [7]  00 00 00 00 01 00 00
  can1  718   [1]  05
  can1  298   [7]  00 00 00 00 01 00 00
  can1  298   [7]  00 00 00 00 01 00 00
  can1  718   [1]  05
  can1  298   [7]  00 00 00 00 01 00 00
  can1  298   [7]  00 00 00 00 01 00 00
  can1  718   [1]  05
  can1  298   [7]  00 00 00 00 01 00 00
  can1  298   [7]  00 00 00 00 01 00 00
debian@ebb:~cansend can1 123#1122334455667788

My only mistake here is I should have put it along side the P8 connector since the metal box has an opening there and the pins of the SOIC carrier don’t interfere with the metal USB connector.
BBB-CANDriverTop

Here’s the wire-wrapped point to point wiring. The red wire on the cable isn’t connected to the board. It’s on the DB9-5 Power pin (12V)
BBB-CANDriverBot

2 Likes

Since I haven’t heard anything back from you I’m assuming you solved the problem?

I couldn’t expect you would do such test. Thank you so much!
I’m sorry for late answer, I was figuring out what’s going on with this cuz I’m not actually majoring in this one though…

So as I understand, you mean that there is a serious defect in the can transceiver chip cjmcu-230, which cannot work right with all 6 marked pins of it. I found this website which shows about the malfunctioning about 230 chip product and people here saying about similar problems that I have.
About the CAN controller. - Page 18 - ESP32 Forum

I really appreciate that you did experiment here!
And I think I don’t have such tool to rearrange that 230 chip and connect pins on each 8 pins,
so I think I have to buy a new CAN transceiver for now.

From that link it appears there may be fake or defective devices. I fortunately have a few of the real ones in stock so it wasn’t a problem and I’ve been planning on adding a CAN transceiver to that proto-board for several years.

There is stock for the 3.3V transceivers in North America. The 251 series in 5V are now 75 weeks delivery. I was able to lock on to 150 of 252 series devices but even they won’t arrive until mid December. There are other parts that are not slated for delivery until Mid August 2022.

Good luck with your project.
John Dammeyer

Thank you for your answers so far!
Yet, I am still waiting for the can transceiver product.
I will let you know if I solve the problem in the way you advised me.

Thank you!

Dear John Dammeyer,

It worked just by changing the CAN transceiver board.
I was using “cjmcu-230”, but now I am using the one from WAVESHARE company. (it seems to have no specific board name)
https://www.waveshare.com/sn65hvd230-can-board.htm

I really appreciate your work and knowledge here, thank you!

Hope great luck with your life
Suyong Choi

Just remember you also need a common ground between CAN nodes. Leave that out and you will have unreliable and untraceable CAN communication errors. Not to mention destroying the CAN driver and potentially even the BBB.
John