[Ovmsdev] Can buses stop after some time

[Mark Webb-Johnson]

Greg,

Incoming frames are sent to the freertos queue with block time = 0. So, they will be discarded if the queue to the listener is full.

Code for that is in can.cpp can::NotifyListeners(), which is called by can::IncomingFrame(), which is called after the RxCallback in CAN_rxtask. That all looks correct to me.

There is another code path into LogFrame, but that is only relevant if the logging is active (which I assume it is not).

Regards, Mark.

> On 7 Jul 2018, at 11:14 AM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> 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
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev