Re: [PATCH 0/5] can: mcp251xfd: workaround double-RX erratum

[Tom Evans <tom_usenet@optusnet.com.au>]

On 12/1/23 09:30, Marc Kleine-Budde wrote:
> On 11.01.2023 23:20:37, Marc Kleine-Budde wrote:
>> this is a proof of concept implementation to work around the
>> "double-RX" erratum found by Stefan Althöfer.
>>
>> With the help of Thomas we found out that the chip has a time window
>> after receiving a CAN frame where the RX FIFO STA register content is
>> not read correctly.

This is being called an "erratum". I take that to mean an admitted bug published by the chip 
manufacturer. Has there been any response from Microchip on this yet? If they could properly 
describe what's wrong, it might lead to more robust work arounds.

I've noticed people know about the "maximum SPI clock rate", and are getting close to it in testing. 
The chip might have more (and more frequent) problems near that limit.

The MCP2517FD has more errata items than the MCP2518FD. Anyone using the earlier chip might be 
seeing more problems than people using the MCP2518FD are.

The MCP2517FD (published Errata item #1) is sensitive to delays between SPI Write and delays between 
writes and Chip Select Deassertion. Some SPI drivers and setups don't use the SPI controller's 
native chip-select, but use GPIO pins for flexibility. On Linux that can result in long delays until 
the GPIO Chip Select is deasserted, and long delays between bytes. There are DMA-based SPI 
controllers without these problems, but there may not be full driver support for them. YMMV.

Anyone seeing a difference in errors between two different SPI controllers might be seeing the 
results of different timing (chip select and byte to byte) between them.

Tom