mirror of https://github.com/ArduPilot/ardupilot
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 |
||
|---|---|---|
| .. | ||
| AP_CAN.h | ||
| AP_CANDriver.h | ||
| AP_CANIfaceParams.cpp | ||
| AP_CANManager.cpp | ||
| AP_CANManager.h | ||
| AP_CANManager_CANDriver_Params.cpp | ||
| AP_CANManager_config.h | ||
| AP_CANSensor.cpp | ||
| AP_CANSensor.h | ||
| AP_SLCANIface.cpp | ||
| AP_SLCANIface.h | ||
| LogStructure.h | ||
| README.md | ||
README.md
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