arndtjonasson
commented
8 years ago The two available CAN bus drivers for Linux on Raspberry Pi were not implemented well in kernel version 3. In kernel version 4, the driver is included from the start and seems to work well.
One identified problem on the VCU is that the Adc, which uses SPI just as the CAN controller does, interferes with the logic for handling the CAN bus. If you don't use the Adc, disable the code for it, for example by letting the function IoHw_Read_AdcSensor return without doing anything.
Another cause of problems was that there could arrive CAN messages in the controller while the interrupt routine was running (in buffer 1, when the original interrupt was for buffer 0), and these would never be read, essentially disabling CAN for the node.
With that, the original problems in this issue have been taken care of (even if the best solution is not known yet).
The logic for receiving plugins on the ECU's relies on not much else happening. It needs to buffer the incoming data at a much earlier stage (in the interrupt routine) or use the full CanTp protocol. Currently, installing a new plugin will fail if there is "a lot" going on on the CAN bus at the same time. I think this is the only remaining problem with CAN bus as such. Some code has reentrance problems when receiving data coming over the CAN bus, such as publishing from two sources to the Ecm at the same time.
When two nodes write almost at the same time to the CAN bus, this may cause the CAN bus to stop working on one of the nodes. This is very likely to happen if for example SCU sends things to VCU and at the same time the TCU is busy with either installing a new plugin, or relaying remote control commands.
It is less likely to happen if the SCU sends data to VCU and VCU publishes something, but eventually, after a minute to an hour, things will fail.