[Ovmsdev] Can buses stop after some time

[Greg D.]

Hi tom,

If log level is set to Warn or better, the driver will issue a message
if there was actual data loss.  I assume that didn't happen.

Given that your status got to 0x40, it appears that buffer 0 got full. 
The next frame should have gone into buffer 1, but I'm guessing that's
when things hung.  Status should have gone to 0xC0 in that case, which
it didn't.  Either there's a chip bug, or we're not set up to properly
recover from the double buffering.  There was a similar issue on the
transmit side, and we had to drop back to n-buffering in software, and
only hand one frame to the chip at a time.

Mark, when a frame comes in, as long as there's a process to receive it,
doesn't it get put into the software queue?  If so, in order for the
hardware to get behind, something must be occupying the system's
attention.  Is there a way to adjust the priority of the receive task,
or maybe run it on the other core?

Greg


Tom Parker wrote:
> On 07/07/18 00:05, Mark Webb-Johnson wrote:
>> Err flags 0x2040. The 0x20 part is the error interrupt. The 0x40 part
>> is "RX0OVR: Receive Buffer 0 Overflow Flag bit”.
>>
>> Where the number on ‘can can2 status’ moving at all? Or completely
>> stuck?
>
> None of the can can2 status numbers change when the can bus is broken.
> After power cycling it they move.
>
>> Seems different than the fault Greg and I are seeing. This one likely
>> to be interrupt flag, or buffer overflow, not being cleared
>> correctly. I’m guessing the overflow because that just doesn’t seem
>> correct in mcp2515::RxCallback(). I’ll focus on that and have a look.
>
> I just checked the car again and it stopped with Rx ovrflw number only
> 1281, half what it got to last time.
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev