Michael Balzer wrote:

> I’m working on the MCP2515 driver at the moment, to try to find out what is causing the OBDII HUD lock-up (and others have seen). Perhaps I’ll find out something when reviewing the driver and shared CAN library. Due to the huge volume of traffic on my Tesla Model S, I get a large number of overruns but don’t see this problem. Maybe it is rare, or we are just not noticing it.

I assume the problem can be triggered by poor Wifi connectivity -- that's the situation at Frank's home. I assume the Wifi driver disables interrupts or context
switches in some situations, which causes the CAN rx task execution pauses.

Just a wild guess though, I would check the source for this pattern if it was open.

Hi Michael,

Interesting theory for the overruns, but I don't think that's what's causing the lockup. I can very reliably lock up CAN 3 by starting the OBD2ECU task while frames are being received, e.g. polling from the HUD. Trashing the CAN 3 bus with wrong speed or other traffic before or after the task starts is fine; it's just at the point the task is started that the issue occurs for me. I've inserted some tracing into the mcp2515.cpp code, and what I'm seeing is that there are never any receive frames indicated. I do see error flags, but simply clearing them (as the code already does) doesn't unlock things. Forcing a read doesn't either. Scratching a hole in my head at this point, as I don't see any commands that reset or clear just the receiver...

** Update** Ok, so I can also get the bus to lock up if I cause the OBD2ECU task to pause for a while (10 seconds) and during that time, power cycle the HUD to cause some junk to get onto the CAN bus. Never get a receive interrupt after that... Simply cycling power on the HUD without the delay in OBD2ECU doesn't fail.

Still scratching the cranium,

Greg