Add the overlays files for WeActStudio USB2CANFDV1

[romainreignier]

Describe the requested feature

First of all, thank you very much for this project. Not only is the project itself interesting and practical, but more importantly, it is very well documented and gives a good example of a complete Zephyr-based project for a beginner like me.

I have seen that you have added the support in Zephyr for the WeActStudio USB2CANFDV1 board here zephyrproject-rtos/zephyr#80259 mentioning that it is a great board to use with your CANnectivity project.

I have already installed candleLight_fw firmware on my USB2CANFDV1 (see here) but I have ordered a second one to try CANnectivity.

I have noticed that the overlays for this board are not present on your repo. If you have already written them, could you please add them?

Also, having support for DFU upgrade on this board might be interested.

Describe alternatives considered

I might write them myself but I have on much experience with the Zephyr RTOS.

[henrikbrixandersen]

First of all, thank you very much for this project. Not only is the project itself interesting and practical, but more importantly, it is very well documented and gives a good example of a complete Zephyr-based project for a beginner like me.

Hey, you're very welcome! Happy to hear that. That was the whole idea behind creating this; primarily a practical solution to a problem, but I also wanted to provide a complete example of a fairly simple, but full-featured, Zephyr-based firmware application.

I have seen that you have added the support in Zephyr for the WeActStudio USB2CANFDV1 board here zephyrproject-rtos/zephyr#80259 mentioning that it is a great board to use with your CANnectivity project.

Yup! Glad you've noticed. We've been building up basic support for both the USB2CANFDV1, the original candleLight, the candleLight FD, and the CANable v2.0. More to come.

I have already installed candleLight_fw firmware on my USB2CANFDV1 (see here) but I have ordered a second one to try CANnectivity.

I saw your post there, sweet.

I have noticed that the overlays for this board are not present on your repo. If you have already written them, could you please add them?

I have written them, yes, but I need to find the time to finish support for dual activity LEDs (RX/TX) in CANnectivity before submitting a PR. Shouldn't be long now, almost done.

Also, having support for DFU upgrade on this board might be interested.

Agreed. I will be reworking the USB DFU support in CANnectivity to work with the new USB device ("next") stack, to provide better support for DFU on boards without a dedicated DFU button. I am hoping to see zmkfirmware/zephyr#39 submitted to upstream Zephyr as well, as this would provide means for entering the built-in DFU bootloader on STM32 directly from CANnectivity.

Describe alternatives considered

I might write them myself but I have on much experience with the Zephyr RTOS.

No worries, have a little patience - the plan is to have CANnectivity overlays for all the boards mentioned above and more.

[henrikbrixandersen]

By the way, you can run CANnectivity on the USB2CANFDV1 board even without a board-specific overlay - only then CANnectivity will not use the RX/TX LEDs.

[henrikbrixandersen]

@romainreignier You are welcome to test #43 and provide feedback.

[romainreignier]

Thank you @henrikbrixandersen I will try to test it this week.

[romainreignier]

Hi @henrikbrixandersen
I have tested the new version of CANnectivity on my USB2CANFDV1 board.

I have build it with this command:

$ west build -b usb2canfdv1 cannectivity/app/ -- -DFILE_SUFFIX=release

Using -DFILE_SUFFIX=usbd_next_release causes this error in my dmesg logs:

[18883.964586] usb 1-2.3.2: new full-speed USB device number 16 using xhci_hcd
[18889.128791] usb 1-2.3.2: New USB device found, idVendor=1209, idProduct=ca01, bcdDevice= 1.01
[18889.128795] usb 1-2.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[18889.128797] usb 1-2.3.2: Product: CANnectivity USB to CAN adapter
[18889.128798] usb 1-2.3.2: Manufacturer: CANnectivity
[18889.128799] usb 1-2.3.2: SerialNumber: 2031393542415002000D0041
[18889.140547] gs_usb 1-2.3.2:1.0: Couldn't send data format (err=-32)
[18889.140552] gs_usb: probe of 1-2.3.2:1.0 failed with error -32

But note that I am on Ubuntu 22.04 with an old 5.15 kernel (5.15.0-126-generic) hence an old version of gs_usb that do not support CAN FD. I don't know if it is related.

So without USB next, I have tested the CAN communication with my other USB2CANFDV1 running candleLight_fw.

Basic communication works between the two:

$ sudo ip link set can0 up type can bitrate 1000000
$ sudo ip link set can1 up type can bitrate 1000000
$ cansend can0 123#DEADBEEF
$ cansend can1 123#DEADBEEF

Using cangen it works too in both direction:

$ cangen can0 -g 1 -D 11223344DEADBEEF -L 8
$ cangen can1 -g 1 -D 11223344DEADBEEF -L 8

But using the cangen command mentioned in candleLight_fw PR, the communications does not works on the RX side of CANnextivity (device can1):

$ cangen can0 -g 0 -p 10 -L 0 -I 0x555

Then check the statistics for the candleLight_fw TX:

$ ip -details -statistics link show can0
19: 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 restart-ms 0 
          bitrate 1000000 sample-point 0.750 
          tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
          gs_usb: tseg1 1..256 tseg2 1..128 sjw 1..128 brp 1..512 brp-inc 1
          clock 40000000 
          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 usb parentdev 1-2.3.2:1.0 
    RX:  bytes packets errors dropped  missed   mcast           
             0       0      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
             0   49203      0       0       0       0

CANnectivity RX:

$ ip -details -statistics link show can1
20: can1: <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 restart-ms 0 
          bitrate 1000000 sample-point 0.750 
          tq 12 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1
          gs_usb: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-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 usb parentdev 1-1:1.0 
    RX:  bytes packets errors dropped  missed   mcast           
             0      21     20       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
             0       0      0       0       0       0

49203 sent but 21 received.

Using CANnectivity for TX side works as expected:

$ cangen can1 -g 0 -p 10 -L 0 -I 0x555

CANnectivity TX:

$ ip -details -statistics link show can1
22: can1: <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 restart-ms 0 
          bitrate 1000000 sample-point 0.750 
          tq 12 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1
          gs_usb: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-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 usb parentdev 1-1:1.0 
    RX:  bytes packets errors dropped  missed   mcast           
             0       0      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
             0   16461      0       0       0       0

candleLight_fw RX:

$ ip -details -statistics link show can0
21: 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 restart-ms 0 
          bitrate 1000000 sample-point 0.750 
          tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
          gs_usb: tseg1 1..256 tseg2 1..128 sjw 1..128 brp 1..512 brp-inc 1
          clock 40000000 
          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 usb parentdev 1-2.3.2:1.0 
    RX:  bytes packets errors dropped  missed   mcast           
             0   16461      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
             0       0      0       0       0       0

On the UX side, you use the RDY LED for the state LED, ON when interface is UP and OFF when interface is DOWN.
And the TX and RX LEDs for the activity on RX and TX side.

But when we plug the board to an USB cable, there is no LED ON at all. I find it disturbing because usually, when we plug a USB device, we have some sign of life.

On the candleLight side, the TX and RX LEDs are both ON when the interface is DOWN and switched OFF to be used as activity LEDs once the interface is UP. The Ready LED is always ON because it is not directly supported in the firmware and I have done it that way in the initialization here.

I have not tested the CAN FD part because my kernel does not support it.

I have not tested the DFU either. Is it supposed to work out of the box with USB2CANFDV1?

Thanks again for adding the support for USB2CANFDV1!

[henrikbrixandersen]

Using -DFILE_SUFFIX=usbd_next_release causes this error in my dmesg logs:

The device_next stack is, as mentioned in the README, experimental. In particular, the STM32 USB device_next drivers have known issues (see e.g. zephyrproject-rtos/zephyr#80820 and #47).

The output, I get on the console, is the following:

[00:00:00.209,000] <dbg> gs_usb: gs_usb_enable: enabled
[00:00:03.488,000] <err> udc: Failed to allocate net_buf 0
[00:00:03.488,000] <err> gs_usb: unsupported host byte order (0x20003df0)

I don't think "udc: Failed to allocate net_buf" is caused by a bug in the CANnectivity firmware, but rather a bug in the Zephyr driver. I have captured the issue here: #50

[henrikbrixandersen]

But using the cangen command mentioned in candleLight_fw PR, the communications does not works on the RX side of CANnextivity (device can1):

$ cangen can0 -g 0 -p 10 -L 0 -I 0x555

I'll try to look into this and see if I can reproduce it. Feel free to open a separate issue on this.

[henrikbrixandersen]

On the UX side, you use the RDY LED for the state LED, ON when interface is UP and OFF when interface is DOWN. And the TX and RX LEDs for the activity on RX and TX side.

Correct.

But when we plug the board to an USB cable, there is no LED ON at all. I find it disturbing because usually, when we plug a USB device, we have some sign of life.

Quite a few of the USB to CAN adapter boards available do not come with a power/USB LED.

On the candleLight side, the TX and RX LEDs are both ON when the interface is DOWN and switched OFF to be used as activity LEDs once the interface is UP. The Ready LED is always ON because it is not directly supported in the firmware and I have done it that way in the initialization here.

You could do something similar in CANnectivity by using a GPIO hog for turning on the RDY LED at boot time and removing the state-gpios property. The RX/TX LEDs won't indicate the state as described above, though.

Feel free to open a separate enhancement issue for this behaviour.

[henrikbrixandersen]

I have not tested the DFU either. Is it supposed to work out of the box with USB2CANFDV1?

I does not, no. The current USB DFU support in CANnectivity relies on having a button for booting into DFU mode.

Once zephyrproject-rtos/zephyr#79794 is merged, I plan to start working on a more flexible DFU entry mechanism.