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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tom,

> >> 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.
That's the plan, yes. We don't have simulations yet to fully explain what's going on and more important to make sure that nothing is missed. Once that is fully understood I'll update the erratasheet. In the meantime I think it makes sense to work on and test the workaround. This was the approach for the max spi frequency bug as well. The initial workaround based on testing only was limiting the clock to 92.5% of clk/2(which proved pretty robust in testing) and was then changed to the now in place 85%.
If your suggestion was to call it bug until being an published erratum, yes - I agree that it might things easier to follow and see at which state we are.

> 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.
That shouldn't be the case. The max frequency given in the erratum was chosen so that nothing can happen at that frequency or below that - at least not for this particular failure mode.

> 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.
Yes, at this point especially with the long delays erratum on the MCP2517FD and the way that most SPI Controllers under Linux behave the MCP2518FD is the much better choice. They're pin compatible anyway and mostly SW compatible (that is true unless you were ignoring things like leaving reserved bits untouched etc.) The MCP2518FD has had the sequence field extended and the LPMEN bit added but that's it. So for 99% of the people there's really no reason to still use the 17FD.

Thomas




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux