UAVCAN Does Not Work on Pixhawk4 Mini

[AlexKlimaj]

Describe the bug

The CAN port on the Pixhawk4 Mini is not working.

When checking the CAN High and CAN Low signals, there is no data being transmitted.

Tested on v1.10.1 Stable and current master.

To Reproduce

1. Set UAVCAN_ENABLE to 1, 2 or 3.
2. Reboot
3. UAVCAN devices never get node ID.

Expected behavior
Turn on UAVCAN through UAVCAN_ENABLE, reboot, connect UAVCAN device, and it will get a node ID. If no device is connected and you scope CAN High and Low, you will see data being transmitted.

Log Files and Screenshots

Pixhawk4 Mini with UAVCAN enabled. CAN High and CAN Low.

Expected behavior: Pixhawk4 Standard with UAVCAN enabled. CAN High and CAN Low.

TXD - Transmit Data input it idling high. Doesn't look like STM32 is sending any data.

[AlexKlimaj]

I pulled open the Pixhawk4 Mini and checked that the pinout is correct.

With UAVCAN_ENABLE set, on boot when I run uavcan status, it is not running. When I run uavcan start, it appears to start. But when I run uavcan status after that, I get a hardfault.

nsh> uavcan status
ERROR [uavcan] application not running
nsh> uavcan start
INFO  [uavcan] Node ID 1, bitrate 1000000
INFO  [uavcan] sensor bridge 'baro' init ok
INFO  [uavcan] sensor bridge 'mag' init ok
INFO  [uavcan] sensor bridge 'gnss' init ok
INFO  [uavcan] sensor bridge 'flow' init ok
INFO  [uavcan] sensor bridge 'battery' init ok
nsh> uavcan status
Pool allup_hardfault: Hard Fault:
up_hardfault:   IRQ: 3 regs: 0x20037cac
up_hardfault:   BASEPRI: 000000f0 PRIMASK: 00000000 IPSR: 00000003 CONTROL: 00000000
up_hardfault:   CFAULTS: 00008200 HFAULTS: 40000000 DFAULTS: 00000000 BFAULTADDR: 00000000 AFAULTS: 00000000
up_hardfault: PANIC!!! Hard fault: 40000000
up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148 task: uavcan
up_registerdump: R0: 00000000 00000001 00000080 20027e80 20035130 20035090 00000002 20035740
up_registerdump: R8: 00000001 08157eb5 08157ea3 08157e94 00000000 20037d80 0805abf1 0805abf0
up_registerdump: xPSR: 61000000 BASEPRI: 000000f0 CONTROL: 00000000
up_registerdump: EXC_RETURN: ffffffe9
up_dumpstate: sp:     20021498
up_dumpstate: IRQ stack:
up_dumpstate:   base: 20021500
up_dumpstate:   size: 00000200
up_dumpstate:   used: 00000158
up_stackdump: 20021480: 00000000 20037df8 20021498 20021500 000007dc 08009c2d 000000f0 00000000
up_stackdump: 200214a0: 08157e94 00000000 20037d80 0805abf1 0805abf0 200214c0 08009769 00000003
up_stackdump: 200214c0: 08157e94 08009771 40000000 00000000 00000000 00000000 20021500 0800b56b
up_stackdump: 200214e0: 000000f0 08008371 000000f0 20037cac 20035090 00000002 20035740 08008237
up_dumpstate: sp:     20037d80
up_dumpstate: User stack:
up_dumpstate:   base: 20037df8
up_dumpstate:   size: 000007dc
up_dumpstate:   used: 000002a8
up_stackdump: 20037d80: 00000015 00000000 00000000 00000000 00000bf8 00000000 00000001 20035090
up_stackdump: 20037da0: 20037dfc 20037e0f 00000000 00000002 00000000 00000000 00000000 0805e2f7
up_stackdump: 20037dc0: 00000001 0800d1fd 200344f0 0800d0cd 00000000 200344f0 00000000 00000000
up_stackdump: 20037de0: 00000000 00000000 00000000 0800c539 00000000 00000000 deadbeef 20037e08
up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
up_taskdump: hpwork: PID=1 Stack Used=344 of 1260
up_taskdump: lpwork: PID=2 Stack Used=344 of 1516
up_taskdump: init: PID=3 Stack Used=1824 of 2604
up_taskdump: wq:manager: PID=4 Stack Used=392 of 1252
up_taskdump: wq:uavcan: PID=389 Stack Used=1456 of 2396
up_taskdump: uavcan: PID=390 Stack Used=680 of 2012
up_taskdump: wq:I2C3: PID=140 Stack Used=920 of 1396
up_taskdump: wq:SPI4: PID=142 Stack Used=568 of 1996
up_taskdump: wq:hp_default: PID=16 Stack Used=1160 of 1900
up_taskdump: wq:UART4: PID=273 Stack Used=672 of 1396
up_taskdump: dataman: PID=18 Stack Used=760 of 1204
up_taskdump: wq:lp_default: PID=20 Stack Used=812 of 1700
up_taskdump: navigator: PID=349 Stack Used=968 of 1764
up_taskdump: gps: PID=222 Stack Used=1056 of 1676
up_taskdump: sensors: PID=163 Stack Used=1064 of 1964
up_taskdump: wq:att_pos_ctrl: PID=164 Stack Used=4992 of 7196
up_taskdump: commander: PID=166 Stack Used=1220 of 3212
up_taskdump: wq:rate_ctrl: PID=167 Stack Used=1128 of 1596
up_taskdump: commander_low_prio: PID=168 Stack Used=716 of 2996
up_taskdump: mavlink_if0: PID=176 Stack Used=1832 of 2572
up_taskdump: mavlink_rcv_if0: PID=177 Stack Used=2624 of 3940
up_taskdump: logger: PID=373 Stack Used=3016 of 3644
up_taskdump: log_writer_file: PID=376 Stack Used=368 of 1164
up_taskdump: wq:SPI1: PID=122 Stack Used=1152 of 1996
up_taskdump: mavlink_if1: PID=254 Stack Used=1664 of 2484
[boot] Rev 0x0 : Ver 0x4 V540 PID=255 Stack Used=2528 of 3940
[boot] Fault Log info File No 4 Length 3177 flags:0x01 state:0
[boot] Fault Logged on 2020-02-22-03:09:55 - Valid
[boot] There is a hard fault logged. Hold down the SPACE BAR, while booting to review!

When I run uavcan start, the TX and RX lines actually start toggling.

And the CAN High and CAN Low look as expected.

When I connect my UAVCAN smart battery, I see the data on TX and RX, but it never gets a node ID. Then when I run uavcan status it hardfaults. The same behavior whether something is connected or not.

[jinger26]

@DanielePettenuzzo @TSC21 @pavel-kirienko any pointers here?

[jinger26]

@dagar FYI

[AlexKlimaj]

Same behavior on 1.9.2 as well.

[LorenzMeier]

@jinger26 It would be good if Holybro had a look.

[AlexKlimaj]

I have verified with Holybro that their schematic is correctly connected to CAN1.

On the STM32.
CAN1_SILENT_S0 -> PH2
CAN1_TX -> PH13
CAN1_RX -> PI9.

On the CAN Transceiver.
CAN1_SILENT_S0 -> S Pin 8
CAN1_TX -> TXD Pin 1
CAN1_RX -> RXD Pin 4

[davids5]

@AlexKlimaj

uavcan start - start uavcan
uavcan start fw - starts the fw update and node ID server (Only on CAN1)

[LorenzMeier]

@AlexKlimaj The other thing to check is if the silent pin is in the right state.

[AlexKlimaj]

Silent pin is low.

Running uavcan start fw, then uavcan status produces the same result. Device never gets an ID and uavcan status produces a hard fault.

nsh> uavcan start fw
INFO  [uavcan] Node ID 1, bitrate 1000000
INFO  [uavcan] sensor bridge 'baro' init ok
INFO  [uavcan] sensor bridge 'mag' init ok
INFO  [uavcan] sensor bridge 'gnss' init ok
INFO  [uavcan] sensor bridge 'flow' init ok
INFO  [uavcan] sensor bridge 'battery' init ok
nsh> uavcan status
Pool aup_hardfault: Hard Fault:
up_hardfault:   IRQ: 3 regs: 0x20037a7c
up_hardfault:   BASEPRI: 000000f0 PRIMASK: 00000000 IPSR: 00000003 CONTROL: 00000000
up_hardfault:   CFAULTS: 00008200 HFAULTS: 40000000 DFAULTS: 00000000 BFAULTADDR: 00000000 AFAULTS: 00000000
up_hardfault: PANIC!!! Hard fault: 40000000
up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148 task: uavcan
up_registerdump: R0: 00000000 00000001 00000080 20027e80 20034f00 20034e60 00000002 20035510
up_registerdump: R8: 00000001 08157eb5 08157ea3 08157e94 00000000 20037b50 0805abf1 0805abf0
up_registerdump: xPSR: 61000000 BASEPRI: 000000f0 CONTROL: 00000000
up_registerdump: EXC_RETURN: ffffffe9
up_dumpstate: sp:     20021498
up_dumpstate: IRQ stack:
up_dumpstate:   base: 20021500
up_dumpstate:   size: 00000200
up_dumpstate:   used: 00000158
up_stackdump: 20021480: 00000000 20037bc8 20021498 20021500 000007dc 08009c2d 000000f0 00000000
up_stackdump: 200214a0: 08157e94 00000000 20037b50 0805abf1 0805abf0 200214c0 08009769 00000003
up_stackdump: 200214c0: 08157e94 08009771 40000000 00000000 00000000 00000000 20021500 0800b56b
up_stackdump: 200214e0: 000000f0 08008371 000000f0 20037a7c 20034e60 00000002 20035510 08008237
up_dumpstate: sp:     20037b50
up_dumpstate: User stack:
up_dumpstate:   base: 20037bc8
up_dumpstate:   size: 000007dc
up_dumpstate:   used: 000002c0
up_stackdump: 20037b40: 00000000 00000000 00000000 0805abe3 00000095 00000000 00000073 00000000
up_stackdump: 20037b60: 00000034 00000000 00000001 20034e60 20037bcc 20037bdf 00000000 00000002
up_stackdump: 20037b80: 00000000 00000000 00000000 0805e2f7 00000001 0800d1fd 20034320 0800d0cd
up_stackdump: 20037ba0: 00000000 20034320 00000000 00000000 00000000 00000000 00000000 0800c539
up_stackdump: 20037bc0: 00000000 00000000 deadbeef 20037bd8 20037bdf 00000000 63766175 73006e61
up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
up_taskdump: hpwork: PID=1 Stack Used=344 of 1260
up_taskdump: lpwork: PID=2 Stack Used=344 of 1516
up_taskdump: init: PID=3 Stack Used=1864 of 2604
up_taskdump: wq:manager: PID=4 Stack Used=384 of 1252
up_taskdump: mavlink_if1: PID=261 Stack Used=1664 of 2484
up_taskdump: mavlink_rcv_if1: PID=262 Stack Used=2544 of 3940
up_taskdump: wq:I2C3: PID=142 Stack Used=820 of 1396
up_taskdump: wq:SPI4: PID=144 Stack Used=568 of 1996
up_taskdump: wq:hp_default: PID=18 Stack Used=1004 of 1900
up_taskdump: wq:UART4: PID=275 Stack Used=664 of 1396
up_taskdump: dataman: PID=20 Stack Used=760 of 1204
up_taskdump: wq:lp_default: PID=22 Stack Used=812 of 1700
up_taskdump: navigator: PID=351 Stack Used=968 of 1764
up_taskdump: gps: PID=224 Stack Used=1056 of 1676
up_taskdump: sensors: PID=165 Stack Used=1064 of 1964
up_taskdump: wq:att_pos_ctrl: PID=166 Stack Used=4992 of 7196
up_taskdump: commander: PID=168 Stack Used=1220 of 3212
up_taskdump: wq:rate_ctrl: PID=169 Stack Used=1016 of 1596
up_taskdump: commander_low_prio: PID=170 Stack Used=716 of 2996
up_taskdump: mavlink_if0: PID=178 Stack Used=1832 of 2572
up_taskdump: mavlink_rcv_if0: PID=179 Stack Used=2640 of 3940
up_taskdump: logger: PID=375 Stack Used=3016 of 3644
up_taskdump: log_writer_file: PID=378 Stack Used=368 of 1164
up_taskdump: wq:SPI1: PID=124 Stack Used=1080 of 1996
up_taskdump: wq:uavcan: PID=382 Stack Used=1560 of 2396

[dagar]

Do you know if this is pixhawk 4 mini specific? Have you tried the pixhawk 4 or another fmu-v5?

Is it possible you're hitting a legitimate hardfault in the uavcan battery code?

[AlexKlimaj]

I've tested on my branch, 1.9.2, and 1.10.1. All exhibit the same behavior on the Pixhawk 4 Mini.

Up until now, I have been doing all my testing on a Pixhawk 4 with no issues.

[AlexKlimaj]

I also just discovered that uavcan on the Pixhawk 4 doesn't work without an SD card inserted.

[davids5]

yes the node server / fw use the SD card

[AlexKlimaj]

@hamishwillee Can you add a note in the UAVCAN documentation that it requires an SD card?

[AlexKlimaj]

fault_2020_02_22_19_07_11.log

Okay, now this is getting weird. I was just able to replicate the behavior on the Pixhawk 4.

Deleting the uavcan folder on the sd card and resetting the uavcan parameters seemed to resolve it.

[hamishwillee]

Hi @AlexKlimaj

Can you add a note in the UAVCAN documentation that it requires an SD card?

Can you confirm that you're saying UAVCAN itself requires an SD card be present to work:

• on all versions of PX4?
• on all Pixhawk hardware (or just Pixhawk 4/mini)?
• and that this effects any UAVCAN peripheral? -e.g. escs/power modules etc?
• UAVCAN0 or 1 or both?

Sounds like an unfortunate dependency - SD card dies and plane falls out of sky?

How to fix depends a bit on above, but probably good to add notes to:

• https://dev.px4.io/master/en/uavcan/
• https://dev.px4.io/master/en/uavcan/notes.html
• https://docs.px4.io/master/en/peripherals/uavcan_escs.html
• https://docs.px4.io/master/en/power_module/

Seem reasonable?

[davids5]

@hamishwillee Unless something has changed, it is only needed while the UAVCAN FW server and node ID allocation is done at boot up. The FW server is stopped after that and the memory is reclaimed.

[jinger26]

also cc @pavel-kirienko @TSC21

[hamishwillee]

@davids5 Thank you. Is there any way for an end user to know or infer that this is a possible reason their (UAVCAN) motors won't start and power module doesn't supply info etc? i.e. this creates a dependency that every PX4 device must have an SD card (at boot) if it may have UAVCAN. That doesn't feel reasonable - but perhaps this is already a requirement somewhere?

Based on your comment, do you think it reasonable I add the following note in various places:

Note UAVCAN requires that an SD Card is present on boot (only).

[davids5]

I would go with, Note UAVCAN requires that an SD.

[hamishwillee]

@davids5 Why omit the "on boot" clarification? I find it comforting to know that if my SD card dies in flight my UAVCAN motors won't :-)

[davids5]

@hamishwillee because you will have to define the moment it is ok to not have it. When will that be?

Use the HW to see how it works with current FW. Testing it on a unit will tell you how it really works, not how we think it works! Please take the initiative to do this sort of thing when questions arise.

Card out of the system.

nsh> uavcan start
INFO  [uavcan] Node ID 1, bitrate 1000000
INFO  [uavcan] sensor bridge 'baro' init ok
INFO  [uavcan] sensor bridge 'mag' init ok
INFO  [uavcan] sensor bridge 'gnss' init ok
INFO  [uavcan] sensor bridge 'flow' init ok
INFO  [uavcan] sensor bridge 'battery' init ok

nsh>  uavcan start fw
ERROR [uavcan] FirmwareVersionChecker init: -1, errno: 19
ERROR [uavcan] Node init failed: -1
ERROR [uavcan] Firmware Server Failed to Start -1

Reinsert card into the system (This will not work)

nsh>  uavcan start fw
ERROR [uavcan] FirmwareVersionChecker init: -1, errno: 19
ERROR [uavcan] Node init failed: -1
ERROR [uavcan] Firmware Server Failed to Start -1
nsh>

reboot - You have to boot with the SD in the system - and then finish FW upgrades and Node ID Allocation. BEFORE you remove the card.

NuttShell (NSH) NuttX-8.2
nsh> INFO  [logger] Opened full log file: /fs/microsd/log/sess079/log001.ulg
INFO  [ecl/EKF] reset position to last known position
INFO  [ecl/EKF] reset velocity to zero
 uavcan start
INFO  [uavcan] Node ID 1, bitrate 1000000
INFO  [uavcan] sensor bridge 'baro' init ok
INFO  [uavcan] sensor bridge 'mag' init ok
INFO  [uavcan] sensor bridge 'gnss' init ok
INFO  [uavcan] sensor bridge 'flow' init ok
INFO  [uavcan] sensor bridge 'battery' init ok
nsh> INFO  [ecl/EKF] 8921779: EKF aligned, (baro height, IMU buf: 22, OBS buf: 14)
uavcan start fw

Just tell the story as it is:

"The SD card is required for UAVCAN Node allocation and firmware upgrade. It is not used during flight by UAVCAN"

[hamishwillee]

@davids5 - Thanks very much. I'll take your advice re the text.

Please take the initiative to do this sort of thing when questions arise.

I am unlikely to do this type of testing. While it is trivial for you, I don't have the knowledge, hardware, or understanding of how to interpret the results. Sorry if that is frustrating - but usually getting expert answers is a better use of everyone's time.

[davids5]

@AlexKlimaj - My FMUv5 mini RC09 would not start UAVCAN

I get

 CAN driver init failed -1006

On investigating it, the board is built with # interfaces = 2, this is incorrect for the HW. But it is a shared bin file for the V5 and the Mini. So that is a problem that needs to be fixed. If I force the driver to return, with only on interface, I get no data on the one interface. I also get a hard fault on the accessing of that interface with uavcan status. That should not happen in the real world as the driver should not start. So the question is why did you board start?

Rebuilding the code with https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v5/default.cmake#L12 set to 1, works on a FMUv5, but there is not traffic on the mini. ....

Looking at the data on the scope, I can see the the polarity of the CAN H and L are swapped on the mini.

FMU V5 Correct
CANL Chan 1 (yellow)
CANH Chan 2 (green)

FMUV5 Mini - is Incorrect!

Looking at the schematics I see there is an error on the Breakout board crossing CANH to CANL.

nsh> var all
nsh: var: command not found
nsh> ver all
HW arch: PX4_FMU_V5
HW type: V500
HW version: 0x00000000
HW revision: 0x00000000
FW git-hash: d7e502ec72af023b870fd41a83e1ec6e86561768
FW version: 1.11.0 0 (17498112)
FW git-branch: master
OS: NuttX
OS version: Release 8.2.0 (134349055)
OS git-hash: 58d2c1c05487d0805ae242d5446cdd9ddae30d0a
Build datetime: Feb 28 2020 09:20:14
Build uri: localhost
Toolchain: GNU GCC, 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
PX4GUID: 000200000000363539373137510100340032
MCU: STM32F76xxx, rev. Z

[AlexKlimaj]

On the Mini hardware I have (which was purchased in December 2019), it is not swapped on the breakout board. I opened it up and verified the pinout from the pin of the CAN transceiver to the GH pin.

I only get the hardfault if I start uavcan manually, then it hardfaults if I do uavcan status. Otherwise, uavcan is not started on the Mini even with the parameter set to turn it on.

[davids5]

@AlexKlimaj - We must have different HW.

Are you using mavlink console?
do a dmesg and you will see that the boot failed to start uavcan, then the second time (you do it manually) it will start, but that is wrong, It should not.

Try rebuilding with https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v5/default.cmake#L12 set to 1, then run it.

[AlexKlimaj]

I am using the debug port.

dmesg shows the failed boot.
ERROR [uavcan] CAN driver init failed -1006

Changing UAVCAN_INTERFACES 2 to 1 solved the problem! No hardfault either.

INFO  [uavcan] Node ID 1, bitrate 1000000
ERROR [uavcan] node spin error -8
INFO  [uavcan] sensor bridge 'baro' init ok
INFO  [uavcan] sensor bridge 'mag' init ok
INFO  [uavcan] sensor bridge 'gnss' init ok
INFO  [uavcan] sensor bridge 'flow' init ok
INFO  [uavcan] sensor bridge 'battery' init ok
NuttShell (NSH)
nsh> uavcan_battery adding channel 125...
uavcan_battery channel 125 class instance 0 ok
INFO  [ecl/EKF] reset position to last known position
INFO  [ecl/EKF] reset velocity to zero
INFO  [uavcan] UAVCAN command bridge: starting global param list with node 125
INFO  [uavcan] UAVCAN command bridge: starting param count
ERROR [uavcan] UAVCAN command bridge: GetSet error during param count
INFO  [uavcan] UAVCAN command bridge: completed param list for node 125

BTW this is the output of ver all.

nsh> ver all
HW arch: PX4_FMU_V5
HW type: V540
HW version: 0x00000004
HW revision: 0x00000000
FW git-hash: ff046c1cfd6de1ab8b7548b392f11fd70372e3c2
FW version: 1.11.0 0 (17498112)
FW git-branch: uavcan_smart_battery
OS: NuttX
OS version: Release 8.2.0 (134349055)
OS git-hash: fdf1837077104e80912a2c46ff159fdacc8b06f9
Build datetime: Feb 28 2020 20:24:02
Build uri: localhost
Toolchain: GNU GCC, 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
PX4GUID: 000200000000353338373138511600450029
MCU: STM32F76xxx, rev. Z
nsh>

And the output of a uavcan status with 2 batteries connected.

nsh> uavcan status
Pool allocator status:
        Capacity hard/soft: 500/250 blocks
        Reserved:  31 blocks
        Allocated: 13 blocks

UAVCAN node status:
        Internal failures: 0
        Transfer errors:   0
        RX transfers:      5012
        TX transfers:      907

CAN1 status:
        HW errors: 0
        IO errors: 0
        RX frames: 27463
        TX frames: 925

control latency: 0 events, 0us elapsed, 0.00us avg, min 0us max 0us 0.000us rms
INFO  [mixer_module] Switched to rate_ctrl work queue: 0
INFO  [mixer_module] Mixer loaded: no
INFO  [mixer_module] Driver instance: 0
INFO  [mixer_module] Channel Configuration:
INFO  [mixer_module] Channel 0: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 1: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 2: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 3: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 4: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 5: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 6: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 7: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 8: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 9: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 10: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 11: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 12: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 13: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 14: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191
INFO  [mixer_module] Channel 15: value: 0, failsafe: 0, disarmed: 65535, min: 1, max: 8191

Sensor 'baro':
devname: /dev/baro
channel 0: empty
channel 1: empty
channel 2: empty
channel 3: empty
channel 4: empty

Sensor 'mag':
devname: /dev/mag
channel 0: empty
channel 1: empty
channel 2: empty
channel 3: empty
channel 4: empty

Sensor 'gnss':
RX errors: 0, using old Fix: 1, receiver node id: N/A

Sensor 'flow':
devname: /dev/flow
channel 0: empty
channel 1: empty
channel 2: empty
channel 3: empty
channel 4: empty

Sensor 'battery':
devname: /dev/battery
channel 0: node id 123 --> class instance 0
channel 1: node id 124 --> class instance 1
channel 2: empty
channel 3: empty
channel 4: empty

Online nodes (Node ID, Health, Mode):
         123 OK         OPERAT
         124 OK         OPERAT

uavcan: cycle time: 177300 events, 6827268us elapsed, 38.51us avg, min 9us max 15425us 66.333us rms
uavcan: cycle interval: 177300 events, 2556.34us avg, min 27us max 139814us 989.084us rms
nsh>

[davids5]

@AlexKlimaj - It was confirmed by the manufacture that the mini's prior to January 23,2019, has the swapped lines. This was mostly proto runs and should not have effected later production. But worth knowing.

Would you please check today's master, compiled with UAVCAN_INTERFACES 2. I would expect it to still need to started manually, but not hardfault.

I will work on the correct fix.

[AlexKlimaj]

@davids5 Looks like the hardfault is fixed.
On boot:

INFO  [uavcan] Node ID 1, bitrate 1000000
ERROR [uavcan] CAN driver init failed -1006

If I start it manually with uavcan start fw the driver starts but does not function. uavcan status no longer hardfaults in this scenario.

If I set UAVCAN_INTERFACES to 1, the driver starts on boot and is functional.

[peterkatwork]

I have a found the same as davids5 (post on Feb 29). The CAN bus high and low connections are physically swapped in the PH4-mini hardware I have. I have a PixHawk4 and a mini, and the 4 has always just worked, but the mini never. Finally got the scope out to look at the signals and they are definitely swapped. This hardware was only bought mid to late last year. I know this is not the main topic of this thread, but it is the only place I have found this pin swap mentioned. Be warned, not all problems are software.

[AlexKlimaj]

I have a found the same as davids5 (post on Feb 29). The CAN bus high and low connections are physically swapped in the PH4-mini hardware I have. I have a PixHawk4 and a mini, and the 4 has always just worked, but the mini never. Finally got the scope out to look at the signals and they are definitely swapped. This hardware was only bought mid to late last year. I know this is not the main topic of this thread, but it is the only place I have found this pin swap mentioned. Be warned, not all problems are software.

Thanks for the update. The firmware bug is fixed, so if UAVCAN is still not working on a Pixhawk 4 Mini, you likely have older hardware with the pins swapped.

[peterkatwork]

FYI, I decided to modify my PH4-mini. Procedure attached. Not a job for the faint hearted or inexperienced solderer.
PixHawk4-mini CAN Bus Mod Proc.pdf

[AlexKlimaj]

Nice looking rework!