Hi @swisstinu,
Thank you very much. Unfortunately it didn’t help. With this Marc’s driver still only up to 4 messages can be sent and none can be received. Did you touch device tree to make it working?
BTW looking into Verdin device tree I see MCP2517FD SPI clock is limited to 2MHz instead of 20. I would try rising it and check if that improves situation with “MAB overflow”.
The problem of mcp25xxfd driver is overlooked address alignment requirement. Quote from datasheet;
Writes and Reads must be word-aligned
Yet Rx payload length prefetch_bytes predict mechanism doesn’t take that into account. Data is destroyed when message len is > prefetch_bytes and prefetch_bytes is not a multiple of 4. To fix:
disable auto prefetch_bytes and specify it:
echo 4 > /sys/module/mcp25xxfd/parameters/rx_prefetch_bytes
0,4, 8… should be fine. To reproduce data damage use 1,2,3,5,…
patch mcp25xxfd_can_rx_predict_prefetch() in mcp25xxfd_can_rx.c. Replace
return cpriv->rx_history.predicted_len;
with
return (cpriv->rx_history.predicted_len + (4-1)) & ~(4-1);
Regards,
Edward
Hi @Edward
Thank you for the hint with the device tree. I now had time to experiment with it…
Changing it to 20MHz shows a bit less RX-0 MAB overflows. Than also changed it to 8.333333MHz like it is suggested in the driver code but this hat also the same effect:
When heavy traffic is on the bus the RX-0 MAB errors still show up.
I have the feeling that SPI <-> CAN is not the best / most robust solution. Think I have to switch to Apalis and Flexcan.
Regards
swisstinu
Hi @swisstinu,
If you played with SPI clock in DT, then please make sure interrupt pin sensitivity is set to level instead of edge. Level sensitivity is right for this chip.
You didn’t say how many messages and at what rate do you have on your CAN bus. If this could be of any help for your, VF61 using Martin Sperl driver at 1Mbps is able to read and process for me about 1.5 kHz equally spaced stream of CAN messages. More messages would require faster CPU or going away from Linux. That’s much worse than using integrated FlexCAN, which allows to process on VF61+Linux fully loaded CAN bus, 29 bit message ID’s.
Regards,
Edward
HI @Edward and @swisstinu
Thanks very much for your Input. The issue you reported here is addressed to our internal R&D team and we will look into this.
have the feeling that SPI ↔ CAN is not the best / most robust solution. Think I have to switch to Apalis and Flexcan.
Depending on your requirements regarding CAN you can switch to Verdin iMX8MP which has two integrated flexcans.
Best regards,
Jaski
Hi @jaski.tx
Thanks for your recommendation regarding iMX8MP. Is this module able to handle CAN-FD traffic up to 8Mbit/s?
When are sample modules expected to be available?
Kind regards
swisstinu
let me comment as well. Nobody is perfect. I mean there are some nuisances with both MCP2518 and CAN FD capable version of FlexCAN module.
8Mbps data bit rate? Yes, both are capable, but don’t forget about CAN bus driver limits, which is another story.
64 byte payload? Yes, both are capable. But not everything is fine. FlexCAN has up to 2x32=64 message buffers… limited to 8 bytes payload. If you need all 64 bytes Rx/Tx, then you need to switch one or both message banks to 64 byte payload format, and when you do so, 32 message buffers bank turns into only 7 message buffers bank. So just 2*7=14 message buffers from both banks. That’s quite bad keeping in mind Linux interrupt latency, as well keeping in mind that some buffers should be reserved to send messages. Standard FlexCAN mode offers DMA support, which would eliminate Rx overflow issue even with so low amount of mailboxes. But DMA is not available in CAN FD mode. With high message rate you may need kernel RT patch or some other solutions (perhaps M4) to read all messages in time. FlexCAN with Linux can be fine, but it depends on application.
MCP2518 has up to ~30 message Tx/Rx buffers, all with 64 byte payload support. That’s good, but SPI. SPI isn’t very bad but needs extra CPU power compared to FlexCAN. RT patch or something still may be required, it depends on your message rates. At 1Mbps arbitration rate you may have 10kmsg/s and even more. All buffers may be filled in 3ms. If your CAN bus never reaches such message rates, then you may be fine.
Regards
Edward
Update regarding different driver versions. I had bug in device tree, interrrupts = <NN GPIO_ACTIVE_LOW> instead of correct interrupts = <NN IRQ_TYPE_LEVEL_LOW>. Fixing that made Marc Kleine-Budde driver working as well. I’m puzzled how Mark Sperl driver was working with that.
Comparing driver performance, I prefer what Toradex has in their kernel. With M. Sperl driver, which comes with Toradex kernel, I can reach 1.7 kmsg/s on VF61, and with M. Kleine-Budde driver I can reach only 1.4 kmsg/s. Above those limits messages start to get lost. You should have better results on i.MX8, VF61 CPU load is just to high to reach better results.
Edward
Hi @Edward
Thanks for your Input. We will consider the driver you tested for Integration.
Best regards,
Jaski
Hi @jaski.tx,
These drivers have chances to change winners on different machine. Different SPI’s, different number of cores. Torvalds git includes M. Kleine-Budde MCP251xfd driver variant already. This is slower on VF61 compared to what you have in your github. If you can, please don’t remove M. Sperl variant from kernel tree, just patch that rx_prefetch_bytes problem and allow choosing one driver or another. Device tree is compatible with both drivers, as well both have different driver folder names, mcp251xfd vs mcp25xxfd, so can coexist in source form.
Regards,
Edward
Hi,
This is Walter from Toradex, I can advise on this topic (Verdin M plus). Shall I contact you on your email address?
Best regards,
WM