RE: mcp251xfd: rx frame truncation (1/2)

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

 




>Update:
>I moved my click boards to the standard RPI and attached the logic analyzer. The same spi0/spi6 16/10 MHz setup.
>However the truncation error has not appeared within 16h. Nevertheless I see lots of Transmit Event
>issues:
 Mhm ☹ That could explain why I can't catch anything. I'm using the Pi4 with the original Seeed Studio HAT(soldered the 18FD onto it instead of the 17FD) on SPI0 and SPI6 and matched your SPI frequencies.

Jan 19 04:17:52 raspberrypi kernel: [43155.280967] mcp251xfd spi6.0 can1: Transmit Event FIFO buffer not empty. (seq=0x000018aa, tef_tail=0x000018ae, tef_head=0x000018af, tx_head=0x000018af). 
Jan 19 04:18:38 raspberrypi kernel: [43200.859040] mcp251xfd spi6.0 can1: Transmit Event FIFO buffer full. (seq=0x00000d42, tef_tail=0x00000d46, tef_head=0x00000d47, tx_head=0x00000d47).
Jan 19 04:48:04 raspberrypi kernel: [44967.518028] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000000ae, tef_tail=0x000000b2, tef_head=0x000000b3, tx_head=0x000000b3).
Jan 19 04:49:03 raspberrypi kernel: [45026.114903] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000015b0, tef_tail=0x000015b4, tef_head=0x000015b5, tx_head=0x000015b5).
Jan 19 04:51:22 raspberrypi kernel: [45165.012206] mcp251xfd spi6.0 can1: Transmit Event FIFO buffer not empty. (seq=0x00000e12, tef_tail=0x00000e16, tef_head=0x00000e17, tx_head=0x00000e18).
Jan 19 05:13:33 raspberrypi kernel: [46496.222321] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x00001c3e, tef_tail=0x00001c42, tef_head=0x00001c43, tx_head=0x00001c43).
Jan 19 05:34:52 raspberrypi kernel: [47775.805160] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x0000244e, tef_tail=0x00002452, tef_head=0x00002453, tx_head=0x00002453).
Jan 19 06:04:57 raspberrypi kernel: [49580.850626] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x0000103a, tef_tail=0x0000103e, tef_head=0x0000103f, tx_head=0x0000103f).
Jan 19 06:28:33 raspberrypi kernel: [50996.403445] mcp251xfd spi6.0 can1: Transmit Event FIFO buffer full. (seq=0x00001ed6, tef_tail=0x00001eda, tef_head=0x00001edb, tx_head=0x00001edb).
Jan 19 09:47:13 raspberrypi kernel: [62916.335751] mcp251xfd spi6.0 can1: Transmit Event FIFO buffer not empty. (seq=0x0000143e, tef_tail=0x00001442, tef_head=0x00001443, tx_head=0x00001444).
Jan 19 09:56:14 raspberrypi kernel: [63457.721406] mcp251xfd spi6.0 can1: Transmit Event FIFO buffer not empty. (seq=0x00001808, tef_tail=0x0000180c, tef_head=0x0000180d, tx_head=0x0000180d).
Jan 19 11:12:44 raspberrypi kernel: [68047.346038] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000022fe, tef_tail=0x00002302, tef_head=0x00002303, tx_head=0x00002303).
Jan 19 11:48:41 raspberrypi kernel: [70204.560171] mcp251xfd spi6.0 can1: Transmit Event FIFO buffer not empty. (seq=0x00001ea8, tef_tail=0x00001eac, tef_head=0x00001ead, tx_head=0x00001ead).
Jan 19 11:59:54 raspberrypi kernel: [70877.645965] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x00000932, tef_tail=0x00000936, tef_head=0x00000937, tx_head=0x00000938).
Jan 19 12:10:23 raspberrypi kernel: [71506.521062] mcp251xfd spi0.0 can0: Transmit Event FIFO buffer not empty. (seq=0x0000135e, tef_tail=0x00001362, tef_head=0x00001363, tx_head=0x00001363).

Are you interrested in analyzing what's going on at those times? If so, what to do in the driver to stop operation
after the message has been issued so I can stop the analyzer and sample the chip registers?

Absolutely interested, yes.  I see the not empty cases pretty often as well and they shouldn't be an issue. I still can't reproduce the buffer full though. I pretty much only look at the raw SPI communication when analyzing this. So whatever you can capture on the SPI traces for SPI6 would be interesting for me to look at. If possible it would be great to capture either CANL or CANH as well. Yes, a full dump of the chip registers and RAM help to correlate things but in the end it's the pure SPI traces that help find problematic timings.
Not sure how much you can log at a time but maybe it's possible to check the dmesg log and then kill your testscript and set a GPIO on the pi to trigger your logic analyzer to stop acquiring data? That would work if the analyzer can keep a couple seconds in a Ringbuffer or something.

Thanks,
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