Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CAN bus problems #62

Open
arndtjonasson opened this issue Sep 11, 2015 · 2 comments
Open

CAN bus problems #62

arndtjonasson opened this issue Sep 11, 2015 · 2 comments

Comments

@arndtjonasson
Copy link
Collaborator

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.

@arndtjonasson
Copy link
Collaborator Author

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.

@arndtjonasson
Copy link
Collaborator Author

I am not sure anymore that there are reentrancy problems in the Ecm, but the code for receiving CAN packages would also be helped by a real CanTp receiver when VCU and SCU both publish at the same time. For now, a fix is to keep waiting for the one that came first, so we at least get some package right. In practice, now, few publishing packages are lost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant