mirror of
https://github.com/ArduPilot/ardupilot.git
synced 2026-11-05 22:38:38 +08:00
Andrew Tridgell
322b7520de
the AP_CANManager::log_text() gets called from debug logging in AP_DroneCAN. It is a method on a common AP_CANManager object which is shared by multiple AP_DroneCAN threads. if two threads call the debug log messages at the same time then we can end up with _log_pos greater than LOG_BUFFER_SIZE (1024) and overwrite past the end of the buffer in the crash_dump we have for this case the next piece of memory was hal.can[0], and the overwrite of the buffer had corrupted the MessageRam_ structurre in the ChibiOS CAN interface code. That led to a hardfault on receive of a CAN message Note that this issue only happens if CAN_LOGLEVEL is set to greater than zero, and the default is zero. So users can avoid the bug by checking they have not changed CAN_LOGLEVEL. Also, this is likely an issue that only happens on startup, as once the two AP_DroneCAN threads are fully running they have the same thread priority so can't pre-empt each other. During startup some messages are sent from the main thread which has a different priority to the AP_DroneCAN threads, and can thus trigger this issue
Testing And Debugging
Testing under SITL
A wide range of DroneCAN peripherals are supported in the SITL simulation system. The simplest way of starting a DroneCAN enabled simulated vehicle is to use sim_vehicle.py.
For a quadplane use: sim_vehicle.py with the option -f quadplane-can
For a quadcopter use: sim_vehicle.py with the option -f quad-can