AP_CANManager: add testing and debugging README

libraries/AP_CANManager/AP_CANTester.cpp

@@ -378,7 +378,7 @@ bool CANTester::test_busoff_recovery()
     uint64_t timestamp;
     AP_HAL::CANIface::CanIOFlags flags;
     AP_HAL::CANFrame bo_frame;
-    bo_frame.id = (12 | AP_HAL::CANFrame::FlagEFF);
+    bo_frame.id = (10 | AP_HAL::CANFrame::FlagEFF);
     memset(bo_frame.data, 0xA, sizeof(bo_frame.data));
     bo_frame.dlc = AP_HAL::CANFrame::MaxDataLen;
     bool bus_off_detected = false;
@@ -401,12 +401,12 @@ bool CANTester::test_busoff_recovery()
         return false;
     }
     gcs().send_text(MAV_SEVERITY_ERROR, "BusOff detected remove Fault.");
-    hal.scheduler->delay(1000);
+    hal.scheduler->delay(4000);
     gcs().send_text(MAV_SEVERITY_ERROR, "Running Loopback test.");
     //Send Dummy Frames to clear the error
-    _can_ifaces[0]->send(bo_frame, AP_HAL::native_micros64(), 0);
-    bo_frame.id += 1;
-    _can_ifaces[1]->send(bo_frame, AP_HAL::native_micros64(), 0);
+    while (!write_frame(0, bo_frame,100)) {}
+    bo_frame.id -= 1;
+    while (!write_frame(1, bo_frame,100)) {}
     //Clear the CAN bus Rx Buffer
     hal.scheduler->delay(1000);
     _can_ifaces[0]->clear_rx();

libraries/AP_CANManager/README.md

@@ -0,0 +1,63 @@
+## Testing And Debugging
+
+In case unavailability of all the CAN modules that we support, I have created a CAN Driver called CANTester. Currently there are following modes inside CANTester:
+
+**1: TEST_LOOPBACK**
+
+This test verifies if the low level ifaces are functioning properly. To do that messages are sent so as to ensure TX buffers are filled to the max, and also read the data of the bus. Sequence of incoming data is tested, and also that no transmitted packet was dropped during transmit.
+
+**2: TEST_BUSOFF_RECOVERY**
+
+This test is only applicable to boards with H7 chip, where the bus off needs to be handled manually. This test is implemented to check if Bus off recovery is handled and recovered properly. Busoff error can be generated by simply shorting the CANH and CANL.
+
+**3: TEST_UAVCAN_DNA**
+
+This test simply creates a uavcan node allocation client and tries to get node allocated, the allocated node needs to match the requested node id for success. This tests AP_UAVCAN and underlying DNA library.
+
+**4: TEST_TOSHIBA_CAN**
+
+This test simply emulates a ToshibaCan ESC on a bus and handles the data sent by Toshiba CAN driver, and and also responds with ESC telemetry.
+
+**5: TEST_KDE_CAN**
+
+This test simply emulates a KDECAN ESC on a bus and handles the data sent by KDE CAN driver, and and also responds with ESC telemetry. Need to supply this command `long MAV_CMD_PREFLIGHT_UAVCAN 1` after enabling KDECAN because need to do Enumeration before use.
+
+A lot more tests will be needing to be added overtime to ensure robustness and maintainability of CAN Ecosystem.
+
+**Testing under SITL**
+
+https://github.com/linux-can/can-utils contains a nice set of utility to do CAN related testings on Linux system. I used Ubuntu for this development, for Ubuntu systems you can simply download this tool using `sudo apt-get install can-utils`
+
+Following are the common commands that can be used while testing or developing:
+* Create Virtual CAN Interface:
+```
+sudo modprobe vcan
+sudo ip link add dev vcan0 type vcan
+sudo ip link set up vcan0
+sudo ip link add dev vcan1 type vcan
+sudo ip link set up vcan1
+```
+* Route one CANSocket to another
+```
+sudo modprobe can-gw
+sudo cangw -A -s vcan0 -d vcan1 -e
+sudo cangw -A -s vcan1 -d vcan0 -e
+```
+* Delete routes
+```
+sudo cangw -D -s vcan0 -d vcan1 -e
+sudo cangw -D -s vcan1 -d vcan0 -e
+```
+* Route SLCAN to VCAN, this allows connecting CAN devices to SITL run via CAN Adapter like the one running in Ardupilot itself.
+```
+sudo modprobe slcan
+sudo slcan_attach -f -s8 -o /dev/ttyACM0
+sudo slcand ttyACM0 slcan0
+sudo ifconfig slcan0 up
+sudo cangw -A -s vcan0 -d slcan0 -e
+sudo cangw -A -s slcan0 -d vcan0 -e
+```
+* Dump can messages:
+```
+sudo candump vcan0
+```