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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev