Ha, I thought 100k was a typo for 1000, sorry...  Yeah, high speed overflow shouldn't be an issue.  On the other hand, low speed means that the time to receive a frame increases 10x, so that opens up a larger window if the chip doesn't like being talked to when actively receiving a frame.  Perhaps there is some interaction between the two sides of the chip?  For example, are there any registers that pertain to both busses?  I only use CAN3, with nothing connected to CAN2.

Greg


Geir Øyvind Vælidalo wrote:
Thanks Greg. This can-bus is only 100kbit and uses less than 10% of the available capacity. It is a low speed, low traffic bus. And currently I don’t do any transmitting on it. 

I don’t see why it shouldn’t work for me, then.

Geir

30. des. 2017 kl. 19:07 skrev Greg D. <gregd2350@gmail.com>:

For what it's worth, I've been using CAN3 for a long time with no lockups, running the OBDII ECU code.  What is different, perhaps, is that all the interactions are at 500k speed (vs 1000), and generally alternate one frame receive, followed by one frame transmit.  So, overflow should never occur unless the OBD2ECU code stops, at which point I probably didn't care.  Standard vs extended has not been a factor, in case that's a question.

The only issue we had was that if you try to transmit several frames back-to-back, the third and subsequent frame sent were all duplicates of the second frame.  That was fixed by adding a delay in the code, hoping that it would be sufficient for the prior frame to actually get sent.  Seems to work, though those frames are typically only sent at startup (request of VIN or ECU Name), not hammered on.

Greg