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