UAVCAN 1 on master (2018-06-12) broken

[thomasgubler]

I have different behaviours when using UAVCAN to control ESCs on CAN1 and CAN2 on a Pixhawk 4.

• CAN1: everything works fine if we are not connected to QGC. When I launch QGC it will request the UAVCAN parameters and I get a hardfault in the send_uavcan function in mavlink_parameters.cpp. This happens because initially the _uavcan_open_request_list pointer is null. I tried returning the function until the pointer is different from null and then it works fine (after several retries).

• CAN2: the issue that I have on CAN1 doesn't occur because the uavcan module fails to get the parameters and therefore send_uavcan is never called.
  This warning comes up when I connect to QGC and CAN2 is used:

WARN  [uavcan] UAVCAN command bridge: starting global param list with node 128
WARN  [uavcan] UAVCAN command bridge: couldn't start parameter count: -2
WARN  [uavcan] UAVCAN command bridge: completed param list for node 128

On a Pixracer's CAN1 I don't have any of the two issues.
Now I will test on other nuttx boards.

[DanielePettenuzzo]

FYI @LorenzMeier @davids5 @thomasgubler

[davids5]

@DanielePettenuzzo as mentioned here #9534 (comment)

Also in case it is not mentioned anywhere, be advised that FW upgrade and dynamic node ID assignment ONLY will occur on the CAN1 bus. This is by design.

What this means is the FW server (for historical RAM size limitation) a separate task under uavcan on the FMU is that is started in the configuration phase and then stopped to conserver RAM. It is responsible for 1) dynamic node ID allocation (think DHCP on can) 2) FW upgrade - using the brickproof bootloader on a UAVCAN node to update the fw on the node. 3) Parameter setting on the nodes. This is where the hardfault was happening and why it is only related to CAN1.

[DanielePettenuzzo]

UAVCAN FW server is not running on CAN2 therefore the function that causes the hardfault is never called.

[thomasgubler]

CAN1: everything works fine if we are not connected to QGC. When I launch QGC it will request the UAVCAN parameters and I get a hardfault in the send_uavcan function in mavlink_parameters.cpp. This happens because initially the _uavcan_open_request_list pointer is null. I tried returning the function until the pointer is different from null and then it works fine (after several retries).

I think it is not fixed for CAN1 @DanielePettenuzzo still has a fix to push

[thomasgubler]

Rough ETA I got from Daniele is noon CEST 2018-06-13

[LorenzMeier]

@DanielePettenuzzo There is also the PR from David with the UAVCAN update which might address a couple of issues.

[dagar]

See #9650

[davids5]

@DanielePettenuzzo - I think this was related to a race that happens because of the F7. I could have been speed, ordering or having 2 CAN interfaces. The Fix is #9652. I found that send_uavcan was called before enque_uavcan_request on the F7. This was not the case on a AUAV X2.1. I am not sure if it related to having 2 can interfaces or we would have seen it on FMUv2 w/2MB

[DanielePettenuzzo]

@davids5 thanks you. Today I also tried with Pixhawk 3 Pro (fmu-v4pro) that has 2 can interfaces and I didn't have this issue.. Instead with the Pixhack v5 (also fmu-v5) I have the same issues as on Pixhawk 4.

[davids5]

@DanielePettenuzzo For the record my assumption above about a race was wrong! The bug has been in the code forever. It was not a race. The dereferencing null on the F4 did not pitch the exception but does on the F7.

Please cross test the PR as well.

[DanielePettenuzzo]

@davids5 will do one more test first thing tomorrow morning although this is the same change I did today and it was working fine.

[davids5]

@DanielePettenuzzo - thank you! The value add will be testing on the new libuavcan that is now on master.

[DanielePettenuzzo]

@davids5 perfect. will do.