Hardfault on arming if CAN_SLCAN_CPORT set non-zero and have SERIAL6_PROTOCOL set to 22

[rmackay9]

@robertlong13 found a hardfault bug in 4.5, but I think it's still present in master. Fortunately, this one can't happen in flight, just on the transition from disarmed to armed if you have SLCAN set up.

If you accidentally leave CAN_SLCAN_CPORT set non-zero and have SERIAL6_PROTOCOL set to 22 (as is currently default on Cubes still; we actually usually have it set to 2, but we have to use SLCAN temporarily to flash/configure our Currawong ESCs), there's a chance of a hardfault every time you arm. I hit this while doing some motor tests today.

update_slcan_port gets called from the main thread (see attached stack trace image) when writing servos/escs, and sets CANIface::_port to nullptr when armed. Meanwhile, the DroneCAN thread might be in the middle of a function that has to dereference CANIface::_port (see my crash dump analysis screenshot).

This is an easy thing for me to mitigate. We already don't usually use SLCAN, so we just have to make sure to use the temporary setup method using CAN_SLCAN_SERNUM (which I wasn't aware of until digging in to this) instead of setting SERIAL6_PROTOCOL to 22.

But, we probably should fix this bug anyway. I'm thinking, instead of clearing _port, we could introduce a flag and replace all the _port == nullptr early returns to use that flag instead. Would that work? Or do I just huck a semaphore in there instead?

[robertlong13]

Thanks, Randy. Sorry, I should have made this as an issue ticket first.