[Ovmsdev] MCP2515 driver bug?
dexter at expeedo.de
Mon Jun 7 04:15:50 HKT 2021
we've been using rollover all the time on the MCP2515. As we don't use
filters, there is -in theory- no point in not using the second buffer.
In reality though, the SPI slowness introduces a serious race issue, as
new frames may arrive while the driver still processes the previous
That issue isn't addressed by that driver as well, in fact their
handling is much worse than ours, even without rollover enabled. As you
can see in their interrupt handler…
…they read the interrupt flags, then check & read both buffers based on
the flags read, then clear all (!) interrupt flags.
So if an interrupt occurs for buffer 0, and the next frame comes in for
buffer 1 right after the driver read the interrupts, their driver will
only read buffer 0 and then clear all interrupts, thus losing that for
SPI can be a SPITA…
Am 06.06.21 um 19:25 schrieb Craig Leres:
> On 6/6/21 9:16 AM, Michael Balzer wrote:
>> I've just found a spot-on post on this issue:
>> Tom suggests implementing a state machine to reproduce the receive
>> order. His analysis & solution looks sound to me.
> Leave it to chip designers to (a) identify issues with their
> implementations and (b) provide a features to work around the issues.
> Poking around github, this rollver enabled driver might be a good
> Looks like it was added less than a year ago via this PR:
> I'm using an (obsolete) chip for the J1850/Class B network in my 6th
> generation Corvette. I am using it with an atmega (running at 20 MHz)
> but the bus is only 10.4 kb/s and the part (HIP710) SPI master which
> precludes using SPI for anything else. I've been working on a
> J1850/CAN bridge so that ovms can access the bus; I had to step up to
> the atmega644/atmega1284 to pick up a second UART which can be used in
> SPI master mode for use with a MCP2515. But I haven't quite debugged
> my SPI2 code...
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the OvmsDev