On 25.01.2023 16:41:50, Tom Evans wrote: > 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'm working with Thomas from Microchip on this actively on this. We're waiting from simulation results from the hardware team... > 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. In Stefan's test setup one SPI bus uses 16.67 MHz and the other 10 MHz. Stefan, Thomas, which chip shows the problem? I have reproduced the problem at 15 MHz on a different SoC (i.MX6). > 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, Thomas found problems with the loopback mode of the MCP2517FD, but we haven't looked deeper into that. > 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. Both Linux based tests system (rpi4, imx6) are using GPIO chip selects. On the other hand Thomas has reproduced the broken RX FIFO STA register read bug on a µC based setup (with a mcp2518fd). As far as we understand it, the problem occurs in a critical timing window between the reception of a CAN frame and the reading of the RX FIFO STA register. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
