Hi Julian.There’s a problem bothering me. Why is the Ethernet device missing after configuring the CAN port?
After disabling the CAN port, the Ethernet port can work normally.
Hi,
I actually could get the NuttX CAN-Drivers to work on CAN 2. Are there any updates of getting the UAVCAN drivers to work on CAN1 at the same time?
Thanks in advance for your help.
I don’t know what the plans are.
@david_s5 do you know the plans regarding socketcan and dronecan internal drivers on H7?
Hi @david_s5 ,do you have any advice for this issue?
Sorry no. I do not, have an idea where it stands.
1 Like
I replicated the steps posted here by @JulianOes and was able to send 11bit CAN frames using a Pixhawk 6x, thanks for the infos!
Unfortunately I am having some trouble with receiving:
I monitor can0 of the Pixhawk using candump on the MAVLink Console in QGC. When sending a frame with a second device, candump shows nothing. When sending a second frame, the second frame and also the first one (in wrong order) gets received by candump.
When running a module in the background that continuously sends out frames over can0, these are not shown in candump. But when additionally sending on the second device, the same thing happens as described above, but one or both of the frames shown by candump are the ones sent by the module in the background instead of the ones received via the physical can bus.
Does anyone know what that behaviour could be caused by?
Hi all,
I’ve been struggling (again) on the canbus these days, just to realized that in the past I’ve never been able to establish a canbus comunication above 125kbps on Nuttx & PX4.
For this project, I’m on PX4 v1.13, hardware: Pixhawk 4 and I had to set in boards/px4/fmu-v5/nuttx-config/nsh/defconfig:
CONFIG_CAN=y
CONFIG_STM32F7_CAN1=y
CONFIG_STM32F7_CAN1_BAUD=125000
and in default.px4board I disabled the uavcan and enabled the tattu_can:
CONFIG_DRIVERS_UAVCAN=n
CONFIG_DRIVERS_TATTU_CAN=y
Then the tattu_can works pretty much straight forward.
I hope this can help some future users 
1 Like
@JulianOes Does this discussion mean that we are missing a basic guide or tutorial on CAN drivers?
Can you help write one? At least a starting point so we can build on it going forward?
Usually this kind of guide would go something like
- Start from an existing driver - here are one or two that are good starting points
- Quick list of the main things you have to derive from and what they do for you/
- Instructions for adding it to the build.
- Instructions for starting it.
- User instructions for any subscriptions/publications that anyone using the feature is going to need.
In an ideal world, there is a worked example that people can modify like the helloworld app. That has been very helpful over the years for getting docs back into good state when things have drifted in the code.
That would be good but we firstly need NuttX to improve the blocking read (if it hasn’t been fixed in the meantime).
Hello, I enabled canfd0 and 1, and when I used cansend can0 5A1#123456111 in nsh, I found that the device could not be found, and the message “if_nametoindex: no such device” was displayed. How should I check this, thank you
Have you tried to first run:
ifup can0
ifup can1
You can also put this in boards/px4/fmu-v6x/init/rc.board_defaults so it runs on startup.
Could you please introduce how to update the NuttX submodule to this hack? My firmware version is 1.13.3, and there will be many compilation errors after the update
Replying to @JulianOes because this post comes closest to my current goal (so far not met): Enabling Cyphal - CAN-FD in PX4 on the ARKFPV flight controller, which employs an STM32H7 and socketcan. After following the recommendations above (see this local PR: Updates for ARKFPV board to use Cyphal-CAN-FD by jwwaite · Pull Request #1 · AIVS-Inc/PX4-Autopilot).
and configuring the system using:
then setting ifup can0, the CAN utility cansend can only successfully send classic can 2.0 frames, but candump reads both classic CAN and CAN-FD frames. For example, cansend can0 123##1DEADBEEF hangs the CAN system, but cansend can0 123#DEADBEEF does not. When the latter command is issued in the ARKFPV nsh shell, it appears on a connected CAN analyzer. But running candump receives both Classic and CAN-FD frames properly:
I have searched for a missing NuttX config parameter, or PX4 parameter, that might control this, without success. All the signals are clean, both for Classic CAN and CAN-FD. This is clearly a setup issue, and the problem exhibited by cansend is exactly the same behavior when PX4 Cyphal is sending any data, such as the once per second heartbeat. Cyphal successfully reads all CAN-FD frames on the bus sent at the proscribed 1 Mbps (arbitration) and 4 Mbps (data) rates but cannot send a simple heartbeat. In fact, all receive traffic stops after the first transmit.
Any ideas?
It’s working now. I dropped the data rate down to the arbitration rate (1 Mbps) and the CAN-FD transmit works as it should. I probably would have done this sooner were it not for the fact that ARKFPV was reading CAN-FD data at 4 Mbps just fine. But apparently, it cannot transmit at those rates, or maybe does not support CAN-FD acceleration.
I tried using the same process for PX4 1.14 cubepilot cubeorange plus but during the built I am facing an error
@JulianOes can you help with this?
Can you tell me the steps you do? That way I can try to reproduce.
we followed this :
step 1 : added this in boards/cubepilot/cubeorangeplus/init/rc.board_defaults
ifup can1
step 2 :in platforms/nuttx/NuttX/nuttx/arch/arm/src/stm32h7/stm32_fdcan_sock.c
- line 2179 const uint8_t n_stdid = 128
+ line 2179 const uint8_t n_stdid = 0
- line 2189 const uint8_t n_extid = 128;
+ line 2189 const uint8_t n_extid = 0;
step3 :added this in boards/cubepilot/cubeorangeplus/default.px4board
CONFIG_BOARD_UAVCAN_INTERFACES=1
step 4 : boards/cubepilot/cubeorangeplus/nuttx-config/nsh/defconfig
CONFIG_NETDEV_CAN_BITRATE_IOCTL=y
CONFIG_NETDEV_IFINDEX=y
CONFIG_NET_CAN=y
CONFIG_NET_CAN_RAW_TX_DEADLINE=y
CONFIG_NET_CAN_SOCK_OPTS=y
CONFIG_NET_CAN_NOTIFIER=y
CONFIG_NET_TIMESTAMP=y
CONFIG_STM32H7_FDCAN1=y
CONFIG_STM32H7_FDCAN2=y
CONFIG_CANUTILS_CANDUMP=y
CONFIG_CANUTILS_CANSEND=y
step 5 : built for cubeorange_plus
then is resulted in error I posted earlier
@JulianOes please check
Ok, thanks. I could reproduce your issue. I read through this thread again and found two hints that were missing in the defconfig:
+CONFIG_NET=y
+CONFIG_NET_UDP=y
With that it seems to compile.
Thank you @JulianOes for your help. The firmware complied after I followed the steps given by you. But after flashing this custom firmware to hardware. Neither Can1 nor Can2 is sending any CAN data.I checked using USB CAN B hardware. Can you explain how cansend and candump is used for sending the data?