Odroid M1 Rockchip CANBUS problems

[chron0]

i dont think it really is HW related, definitely not bus or transceiver i tested every possible combination there and it all works with the candlelight.
given the fact that a canboot device query works without a problem over the rockchip CAN even on 1M (the reason why I originally marked this as solved,as that was my only available test case at the time), I rather suspect kernel/driver here.
I shared the waveforms before, they looked alright so far. I think this is rather a race condition happening on the Rockchip/Odroid.
I found something interesting in the firefly wiki (also using a rockchip) - they were noting that you definitely have to bump the can frequency in the dtsi to 300MHz for higher speeds to work reliably.
Given that the canboot query works fine but the bus starts to run errors as soon as klipper is running I suspect something like this.
I guess this is due to the way klipper is using the canbus, it's actually not really CAN as intended but what they do is basically wrap their normal serial protocol over CAN frames and spam the bus with it.
In any case I have already recompiled the kernel to 300MHz and will test again if I can get stable klipper communication on 500k and then slowly try to raise the bar to see if that changes anything.

[chron0]

bad news, even with 300MHz in the kernel config, klipper still will run into errors communicating over that canbus. I have basically tried any possible combination, transceiver, wires. there is also a strange behavior on error states: if there are bus errors, the candlelight counts them under error-passes - meanwhile rockchip_can actually pushes the bus-error count up. simple loopback or singe packet can queries work, but it all falls apart if the bus is getting loaded. same physical bus is working with candlelight adapter tho :/ And I really wanted to avoid having to put a separate USB/CAN adapter into this build

Full test log: https://odysee.com/@Apollo-NG:2/voron-2 ... G6Z&t=8319

@tobetter: if you have any ideas or could replicate this with klipper and an Odroid M1 to further investigate this I would be very grateful since I dont wanna give up on native CAN just yet...

[tobetter]

@chron0, ordered one EBB42 and will be reached to me by next week. I and @steve.jeong will try Klipper on M1 and see why CAN has an issue.

[chron0]

@chron0, ordered one EBB42 and will be reached to me by next week. I and @steve.jeong will try Klipper on M1 and see why CAN has an issue.

<3 - looking forward to see what you guys can come up with - i will use the candlelight for the time being but it think it would be great
to have the Odroid M1 as a viable full native communication platform for klipper and the Voron Community in particular.

[steve.jeong]

@chron0, ordered one EBB42 and will be reached to me by next week. I and @steve.jeong will try Klipper on M1 and see why CAN has an issue.

<3 - looking forward to see what you guys can come up with - i will use the candlelight for the time being but it think it would be great
to have the Odroid M1 as a viable full native communication platform for klipper and the Voron Community in particular.

It took some time to set up.

I filmed a video that works with a simple G-code.
I set a can-clock frequency 300M.




I found some errors in the cases.
1. The can-bus wire should not be too long.
2. Print speed should not be too fast. (I raised the print speed to 500%, Mcu is disconnected.)

I will test more and longer.
I'll share it as soon as I find something new.

After running the 3d printer for about 30 minutes,
my can bus state is

Code: Select all

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc fq_codel state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-WARNING (berr-counter tx 0 rx 0) restart-ms 0 
	  bitrate 500000 sample-point 0.818 
	  tq 181 prop-seg 4 phase-seg1 4 phase-seg2 2 sjw 1
	  rockchip_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..128 brp-inc 2
	  clock 297000000 
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          3931       0          1          4          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    244683     33568    3931    82      0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    32436      5062     0       0       0       0       

[chron0]

nice - here is what my bus state looks like with the candlelight with 7 days uptime:

Code: Select all

ip -details -statistic link show can1
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1024
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 500000 sample-point 0.875
	  tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 6
	  gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1
	  clock 48000000 
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          4          74651      0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX:  bytes  packets errors dropped  missed   mcast           
     349471643 55072622      0       0       0       0 
    TX:  bytes  packets errors dropped carrier collsns           
     362813932 55015131      0       0       0       0 

the bus is always the same length/config, about 1.2m, shielded twisted pair, shield only grounded on one side (to avoid ground loop issues).

I think the noteworthy differences between rockchip CAN and candlelight CAN is the error handling:

my state on the candlelight is ERROR-ACTIVE, while the rockchip CAN interface goes into ERROR-WARNING. Same goes for the actual handling of those
errors: First, bus-errors counter: candlelight 0, rockchip quite a lot. Meanwhile the candlelight puts most errors (like if the counterpart device
isnt available) into the error-pass counter. RX/TX error counters on candleight remain at 0 while the rockchip RX error counter goes up.
I can see the exact same behavior on mine on the exact same physical bus and often creating some kind of race condition where
a full reboot of the system is needed (no more network access to it).

also noteworthy: it looks like on "normal" operation (like with the candlelight) the RX/TX ratio seems to be pretty even, the rockchip
CAN is always seeing way more RX packet counters...

maybe we could get the original rockchip CAN driver authors into the game, iirc their emails were in the driver files.

[steve.jeong]

nice - here is what my bus state looks like with the candlelight with 7 days uptime:

Code: Select all

ip -details -statistic link show can1
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1024
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 500000 sample-point 0.875
	  tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 6
	  gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1
	  clock 48000000 
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          4          74651      0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX:  bytes  packets errors dropped  missed   mcast           
     349471643 55072622      0       0       0       0 
    TX:  bytes  packets errors dropped carrier collsns           
     362813932 55015131      0       0       0       0 

the bus is always the same length/config, about 1.2m, shielded twisted pair, shield only grounded on one side (to avoid ground loop issues).

I think the noteworthy differences between rockchip CAN and candlelight CAN is the error handling:

my state on the candlelight is ERROR-ACTIVE, while the rockchip CAN interface goes into ERROR-WARNING. Same goes for the actual handling of those
errors: First, bus-errors counter: candlelight 0, rockchip quite a lot. Meanwhile the candlelight puts most errors (like if the counterpart device
isnt available) into the error-pass counter. RX/TX error counters on candleight remain at 0 while the rockchip RX error counter goes up.
I can see the exact same behavior on mine on the exact same physical bus and often creating some kind of race condition where
a full reboot of the system is needed (no more network access to it).

also noteworthy: it looks like on "normal" operation (like with the candlelight) the RX/TX ratio seems to be pretty even, the rockchip
CAN is always seeing way more RX packet counters...

maybe we could get the original rockchip CAN driver authors into the game, iirc their emails were in the driver files.

I also think there is a problem with the error handling difference.
However, several cases are worth testing before modifying the driver code directly.

If the error state is a problem, we can give the hardware reset time with an option that is restart-ms.
We can also increase the reliability of the message itself with the triple-sampling option.

If it is solved by a higher layer than the CAN driver(ex. ip command), I think it is right to modify the manual.
Driver code is for basic mechanism and it is the job of the higher layer to create and change various conditions.
(+ It's been confirmed that it's already running for about 1~2h.)

Anyway, I will continue to do various tests until this week.
As you said, if the rockchip_can driver needs to modify the driver code, I will reflect it through email or PR.

[chron0]

I have tried triple-sampling already - that did not make a difference, as a matter of fact I started out with triple-sampling enabled (as it seemed like a good option to reduce possible bus error rate) but there was basically NO in-depth info on the net about the specific pros and cons of using it. In later tests I also disabled triple-sampling to make sure it wasn't causing the issue - but it behaved the same way.

I even tried different termination schemes on the different transceivers - i.e. not just a simple 120ohm resistor over H and L but the more "advanced" two 60 ohm resistors connected to H and L and the center of those 2 connected via cap to GND, which supposedly also helps with bus stability and noise/interference reduction - again, no change in behavior.

The only other possibility that comes to my mind is a clock issue - after looking at some other canbus drivers I found they mostly had fixed clocks in there - what if the specific clocks and clockrates/dividers we run on the odroid m1 have something to do with it? other drivers i passed by had specific rates defined for the clocks while we seem to get that from the CRU:

Code: Select all

     can0: can@fe570000 {
         compatible = "rockchip,canfd-1.0";
         reg = <0x0 0xfe570000 0x0 0x1000>;
         interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
         clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
         clock-names = "baudclk", "apb_pclk";
         resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
         reset-names = "can", "can-apb";
         tx-fifo-depth = <1>;
         rx-fifo-depth = <6>;
         status = "disabled";
     };

Also, even though I think it is unlikely or it _should not_ be an issue - but could dynamic frequency scaling of the CPU cause issues?

[steve.jeong]

The only other possibility that comes to my mind is a clock issue - after looking at some other canbus drivers I found they mostly had fixed clocks in there - what if the specific clocks and clockrates/dividers we run on the odroid m1 have something to do with it? other drivers i passed by had specific rates defined for the clocks while we seem to get that from the CRU:

Code: Select all

     can0: can@fe570000 {
         compatible = "rockchip,canfd-1.0";
         reg = <0x0 0xfe570000 0x0 0x1000>;
         interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
         clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
         clock-names = "baudclk", "apb_pclk";
         resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
         reset-names = "can", "can-apb";
         tx-fifo-depth = <1>;
         rx-fifo-depth = <6>;
         status = "disabled";
     };

Also, even though I think it is unlikely or it _should not_ be an issue - but could dynamic frequency scaling of the CPU cause issues?

Although The clock is dynamically assigned, and the CAN driver has difference of error-handling, It doesn't seem like a problem.
There's no problem testing it for a long time
And I don't use twisted-pair wires(length is 3m) and CANbus 120 ohms only connected.
Even if I intentionally disconnect and reconnect, it works fine.
Of course, I will continue to check the difference of error handling.

Code: Select all

$ ip -d -s link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc fq_codel state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can <TRIPLE-SAMPLING> state ERROR-PASSIVE (berr-counter tx 0 rx 0) restart-ms 100 
          bitrate 500000 sample-point 0.818 
          tq 181 prop-seg 4 phase-seg1 4 phase-seg2 2 sjw 1
          rockchip_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..128 brp-inc 2
          clock 297000000 
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          6441803    0          2          6          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    52026984   6510849  6441803 0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    83428      12505    0       0       0       0       

when I connected, I used the script like this.

Code: Select all

#!/bin/bash

sudo ifconfig can0 down
sudo ip link set can0 type can bitrate 500000 restart-ms 100 triple-sampling on
sudo ifconfig can0 up
sudo systemctl stop klipper
sudo systemctl start klipper

The only thing that matters is that I changed the can-clock to 300M.
There is a difference in error handling, but there is no problem with the operation.

What is the version of Klipper firmware? what is the version of kernel version?
Let's get back to the test env.





my env:

kernel version

Code: Select all

$ uname -a
Linux server 4.19.219-odroid-arm64 #1 SMP Thu, 27 Apr 2023 03:27:25 +0000 aarch64 aarch64 aarch64 GNU/Linux

kernel diff

Code: Select all

$ cd linux
$ git log
commit b67d96f3f451b15817d6a2a3162ab983f83187b3 (HEAD -> odroidm1-4.19.y, origin/odroidm1-4.19.y)
Author: Steve Jeong <how2soft@gmail.com>
Date:   Mon May 8 10:06:53 2023 +0900

    squash! ODROID-M1: driver/i2c: Add driver "speed" attribution
    
    Signed-off-by: Steve Jeong <how2soft@gmail.com>
    Change-Id: Ic4c0ec43aec24758b2c42649ca60446eff7dab5c

commit d997a909258b4dc02b7def2b64de6e51f07e40fb
Author: Steve Jeong <how2soft@gmail.com>
Date:   Fri Apr 7 12:03:14 2023 +0900

    ODROID-M1: driver/i2c: Add driver "speed" attribution
    
    for change i2c bus freq dynamically.
    
    e.g.
      $ echo 400000 | sudo tee /sys/bus/i2c/devices/i2c-0/device/speed
    
    Signed-off-by: Steve Jeong <how2soft@gmail.com>
    Change-Id: Ifcccf9bb61ed65133b64c803b53fb4e46d470e26

$ git diff
diff --git a/.scmversion b/.scmversion
index e69de29bb2d1..468fa756cbea 100644
--- a/.scmversion
+++ b/.scmversion
@@ -0,0 +1 @@
+-odroid-arm64
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi
index 4263f9d89dff..61ff2bf0be37 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi
@@ -364,7 +364,7 @@
 
 &can0 {
        assigned-clocks = <&cru CLK_CAN0>;
-       assigned-clock-rates = <150000000>;
+       assigned-clock-rates = <300000000>;
        pinctrl-names = "default";
        pinctrl-0 = <&can0m1_pins>;
        status = "disabled";

klipper version

Code: Select all

$ cd klipper
$ git log
commit 33b18fd62ba73c90054a7b94b68c341bb3f40d9a (HEAD -> master, origin/master, origin/HEAD)
Author: Frederic Morin <frederic.morin.8@gmail.com>
Date:   Sun Mar 5 19:15:43 2023 -0500

    stm32f7: add support for stm32f7 and remram board
    
    Signed-off-by: Frederic Morin <frederic.morin.8@gmail.com>

commit a3eebab4f2b90822f76de91487ff3d4158b80494
Author: Eric Callahan <arksine.code@gmail.com>
Date:   Wed May 3 06:05:37 2023 -0400

    util: report git version info as a dict
    
    Signed-off-by:  Eric Callahan <arksine.code@gmail.com>

And now I'm going to look for a case that doesn't work.
Let's find out why it's not working

[steve.jeong]

We will change the default can-clock frequency of the kernel to 300M and provide a Ubuntu image with mainsailos installed. Let's test it together on the same image

[chron0]

Alright, lets see:

Yes, I am using CANBOOT on the EBB - basically this guide right here: https://maz0r.github.io/klipper_canbus/ ... _v1.1.html

### Interface config ###

A) Rockchip Native (nothing connected to the transceiver atm)

Code: Select all

#!/bin/bash

#/bin/ip link set can0 type can bitrate 500000 triple-sampling on
/bin/ip link set can0 type can bitrate 500000
/bin/ip link set can0 txqueuelen 512  
/bin/ip link set can0 up

Code: Select all

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 512
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
	  bitrate 500000 sample-point 0.818
	  tq 181 prop-seg 4 phase-seg1 4 phase-seg2 2 sjw 1 brp 54
	  rockchip_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..128 brp_inc 2
	  clock 297000000 
	  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 
    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 

B) Candlelight (klipper currently using this)

Code: Select all

#!/bin/bash

#/bin/ip link set can1 type can bitrate 500000 triple-sampling on
/bin/ip link set can1 type can bitrate 500000
/bin/ip link set can1 txqueuelen 1024
/bin/ip link set can1 up

Code: Select all

4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1024
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 500000 sample-point 0.875
	  tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 6
	  gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1
	  clock 48000000 
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          4          109470     0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX:  bytes  packets errors dropped  missed   mcast           
     135966762 21398646      0       0       0       0 
    TX:  bytes  packets errors dropped carrier collsns           
     140404150 21287021      0       0       0       0 

what I can see here directly is the obvious missing restart-ms you introduced but your txqueuelen is also very small (10).
Have you tried printing and really pushing it like running a resonance test with the built-in adxl345 yet? this should
be one of the most demanding tasks on the bus regarding data/timing, apart from QGL which doesnt seem to
be possible to test on your machine.

Also, just tested a couple of minutes ago: updating a new klipper firmware via CANBOOT over this interface
works without a problem.

### Kernel ###

Code: Select all

V0R0N ~ # uname -a
Linux V0R0N 4.19.219-odroid-arm64 #60 SMP PREEMPT Sun Apr 16 14:29:46 UTC 2023 aarch64 GNU/Linux

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi
index 4263f9d89..61ff2bf0b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb.dtsi
@@ -364,7 +364,7 @@
 
 &can0 {
        assigned-clocks = <&cru CLK_CAN0>;
-       assigned-clock-rates = <150000000>;
+       assigned-clock-rates = <300000000>;
        pinctrl-names = "default";
        pinctrl-0 = <&can0m1_pins>;
        status = "disabled";

### Klipper Versions ###

Code: Select all

mcu(stm32f446xx)
Version: v0.11.0-190-g19877425
Load: 0.00, Awake: 0.00, Freq: 180 MHz, Temp: 26°C

mcu EBB36(stm32g0b1xx)
Version: v0.11.0-190-g19877425
Load: 0.06, Awake: 0.01, Freq: 64 MHz, Temp: 29°C

mcu ODROID(linux)
Version: v0.11.0-114-g0a645e49
Load: 0.47, Awake: 0.00, Freq: 50 MHz,

Host(aarch64, 64bit)
Version: v0.11.0-200-g7511151a-dirty
OS: Gentoo Linux
Distro: Gentoo Base System 2.13
Load: 0.5, Mem: 292.2 MB / 7.3 GB, Temp: 26°C
can1 : Bandwidth: 1.2 kB/s , Received: 129.1 MB , Transmitted: 133.3 MB
end0 (10.1.1.121) : Bandwidth: 9.7 kB/s , Received: 1.3 GB , Transmitted: 299.0 GB
can0 : Bandwidth: 0.1 kB/s , Received: 0.1 kB , Transmitted: 0.1 kB

we can still see that my setup still runs a very symmetric rx/tx ratio on the CANbus, while with the
native rockchip_can there is a magnitude or 2 of RX over TX, which doesnt really make sense to me.

[steve.jeong]

First, I think we need to unify the test cases and cross-check them from both sides.
As I said before, the mainsailos M1 image will be released tomorrow or the day after tomorrow.
You can use it by preparing and applying only printer.cfg separately.
I ordered EBB36 can v1.1. When the image is released, I can use it.

what I can see here directly is the obvious missing restart-ms you introduced but your txqueuelen is also very small (10).
Have you tried printing and really pushing it like running a resonance test with the built-in adxl345 yet? this should
be one of the most demanding tasks on the bus regarding data/timing, apart from QGL which doesnt seem to
be possible to test on your machine.

Also, just tested a couple of minutes ago: updating a new klipper firmware via CANBOOT over this interface
works without a problem.

I didn't have a problem even if I didn't expand the tx queue further.
But I don't understand this part, "Have you tried printing and really pushing it like running a resistance test with the built-in adxl345 yet?"
Can I know what kind of test it is? Does it mean that change the xyz acceleration?
Can you share a time stamp from the video link you shared?


I connected the EBB42 through rockchip native-CAN and printed the vu8m-case.gcode file. (I didn't use filament because i tested it in the office.)
Shall we organize the test case together as soon as the image is released?

[chron0]

I ordered EBB36 can v1.1. When the image is released, I can use it.

i think there should be not much difference other than form factor between ebb36 and the ebb42 you got - but when you get an EBB36 V1.1
we have exactly the same.

I didn't have a problem even if I didn't expand the tx queue further.
But I don't understand this part, "Have you tried printing and really pushing it like running a resistance test with the built-in adxl345 yet?"
Can I know what kind of test it is? Does it mean that change the xyz acceleration?

It is called input shaping in klipper terms - it tries to "rattle" the machine on different speeds/frequencies to figure out the resonance
frequencies of the motion frame/belts and measures the accelerations with the adxl345 that is embedded on the EBB.

https://www.klipper3d.org/Measuring_Resonances.html
https://www.klipper3d.org/Resonance_Compensation.html

I havent done that measurement run during my rockchip canbus testruns since I didnt even get a stable klipper connection going,
so there was no point in trying that. and the higher the frequency goes in the test goes the more the bus is going to be strained.
at least that was the common thread in voron discord about can bus speeds (500k minimum, 1M better) for these tests.

[steve.jeong]

New image is released https://dn.odroid.com/RK3568/ODROID-M1/ ... 519.img.xz
It's still an unofficial image.

edit /boot/config.ini to setup can.
the default can clock freq is 300M

Code: Select all

$ vi /boot/config.ini

Code: Select all

[generic]
#default_console=ttyFIQ0
overlay_resize=16384
overlay_profile=
overlays="can0"

[overlay_custom]
overlays="i2c0 i2c1"

[overlay_hktft32]
overlays="hktft32 ads7846"

I set up the can and did the test, which was weird.
I replaced only the board from the ebb42 CAN v1.0 board to the ebb36 CAN v1.1 board while maintaining the interface, but I couldn't connect.
Just like you compared Candlelight.

i think there should be not much difference other than form factor between ebb36 and the ebb42 you got - but when you get an EBB36 V1.1
we have exactly the same.

I agreed with you, but the result was different.
CAN is a standard protocol. I don't understand what happened

When I think about the difference between the two products, the biggest thing is the difference between the CPU.
EBB CAN V1.0 use stm32f072. EBB CAN V1.1 use stm32G0B1
The CAN-related differences between the two models are as follows.

Nothing special and the stm32g0b1 chip supports can-fd.



There are three choices here.

option 1) you can change EBB36 CAN v1.1 to EBB36 CAN v1.0 that uses the same chip as EBB42 CAN v1.0
It's a temporary but simple solution. If you use the image above, it will be available immediately.

option 2) without changing the board, modify and use the Rockchip CAN driver.
But Rockchip stopped updating the can driver, so it's hard to lean on them.

option 3) It is to test again by changing from can to can-fd.
Rockchip can-fd driver has been updated until recently. It's worth trying.

[steve.jeong]

option 3) It is to test again by changing from can to can-fd.
Rockchip can-fd driver has been updated until recently. It's worth trying.

The result is successful.
As well as using the EBB36 CAN v1.1, it has been confirmed that the existing EBB42 v1.0 is also connected to the same bus!

I need to update the dtbo generically, so i have to confirm other cases. I'll share dtbo file as soon as it's organized.
Or you can modify the device-tree and apply it yourself.
change compatible = "rockchip,can-1.0" to compatible = "rockchip,canfd-1.0" in can0 section.

how to setup can-fd:

Code: Select all

$ sudo ifconifg can0 down
$ sudo ip link set can0 type can bitrate 500000 dbitrate 4000000 fd on
$ sudo ifconfig can0 up

I will share the success video tomorrow.

[steve.jeong]

I connected EBB42 CAN V1.0 and EBB36 CAN V1.1 to CAN bus for CAN test.
This is the CANBUS status after using the printer for about 20 minutes.

Code: Select all

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc fq_codel state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can <FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
          bitrate 500000 sample-point 0.868 
          tq 20 prop-seg 42 phase-seg1 43 phase-seg2 13 sjw 1
          rockchip_canfd: tseg1 1..128 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 2
          dbitrate 4013513 dsample-point 0.729 
          dtq 6 dprop-seg 13 dphase-seg1 13 dphase-seg2 10 dsjw 1
          rockchip_canfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 2
          clock 297000000 
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          6          4          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    112573     15419    6       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    21828      3496     4       0       0       0       

There's almost no error
Let's test adxl345 now
Could you please try it yourself and share the test results while I organize CAN?

[steve.jeong]

I tested resonance of axis x, y
I repeated it five times.

My CANBUS status is as follows.

Code: Select all

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc fq_codel state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can <FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 500000 sample-point 0.868
          tq 20 prop-seg 42 phase-seg1 43 phase-seg2 13 sjw 1
          rockchip_canfd: tseg1 1..128 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 2
          dbitrate 4013513 dsample-point 0.729
          dtq 6 dprop-seg 13 dphase-seg1 13 dphase-seg2 10 dsjw 1
          rockchip_canfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 2
          clock 297000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          10         1454       0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
    RX: bytes  packets  errors  dropped overrun mcast
    26035655   3430524  10      0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    150833     22861    1454    0       0       0

I share one x-axis data among the results.

[steve.jeong]

I have completed the can modification.

You will follow this process.

New image is released https://dn.odroid.com/RK3568/ODROID-M1/ ... 519.img.xz
It's still an unofficial image.

edit /boot/config.ini to setup can.
the default can clock freq is 300M

Code: Select all

$ vi /boot/config.ini

Code: Select all

[generic]
#default_console=ttyFIQ0
overlay_resize=16384
overlay_profile=
overlays="can0"

[overlay_custom]
overlays="i2c0 i2c1"

[overlay_hktft32]
overlays="hktft32 ads7846"

After following the above process, you need to proceed with the update and upgrade.

Code: Select all

$ sudo apt update && sudo apt upgrade -y

check kernel version: this version or later

Code: Select all

$ uname -a
Linux server 4.19.219-odroid-arm64 #1 SMP Thu, 25 May 2023 07:30:01 +0000 aarch64 aarch64 aarch64 GNU/Linux

Changed the can driver to canfd driver.

Default can-clock-rate is 200M. To change the can-clock-rate, modify arch/arm64/../overlays/odroidm1/can0.dts

Code: Select all

diff --git a/arch/arm64/boot/dts/rockchip/overlays/odroidm1/can0.dts b/arch/arm64/boot/dts/rockchip/o
verlays/odroidm1/can0.dts
index b52f17eec569..bac729a80021 100644
--- a/arch/arm64/boot/dts/rockchip/overlays/odroidm1/can0.dts
+++ b/arch/arm64/boot/dts/rockchip/overlays/odroidm1/can0.dts
@@ -8,7 +8,7 @@
 
                __overlay__ {
                        status = "okay";
-                       assigned-clock-rates = <200000000>;
+                       assigned-clock-rates = <300000000>;
                };
        };
 };

How to set up canfd:

Code: Select all

$ sudo ip link set can0 type can bitrate 500000 dbitrate 4000000 fd on
$ sudo ifconfig can0 up

Then, copy & paste your printer.cfg to ~/printer_data/config.

restart klipper

Code: Select all

$ sudo systemctl restart klipper