[Ovmsdev] Problems with IncomingFrameCan when registering two can buses.

[Michael Balzer]

Geir,

can you please try this: locate the speed setup in mcp2515.cpp, it's around line 115. Replace the setup for 100 KBPS by this:

    case CAN_SPEED_100KBPS:
      //cnf1=0x03; cnf2=0xfa; cnf3=0x87;
      cnf1=0x44; cnf2=0xe5; cnf3=0x83;
      break;

Then try again.


Am 30.12.2017 um 20:25 schrieb Geir Øyvind Vælidalo:
> I don’t have anything connected to CAN3. I could try to use CAN3 instead of CAN2. It’s a long shot, but worth a try… I’ll look into it tomorrow.
>
> Geir
>
>> 30. des. 2017 kl. 19:29 skrev Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>>:
>>
>> 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 at gmail.com <mailto:gregd2350 at 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
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171230/4fcdb1b6/attachment.htm>