Please keep the mailing list on Cc. On 16.02.2021 11:11:34, Torin Cooper-Bennun wrote: > On Tue, 16 Feb 2021 at 10:28, Marc Kleine-Budde wrote: > > You might not, but the driver does :) > > Indeed, on closer inspection I can see that! > > > If the process repeats infinitely then the CAN controller doesn't go > > into bus-off, which means the CAN bus is terminated correctly. > > > > With your setup of only one node on the bus and correct termination, I > > too think the frame should be send until the ACK field. I suggest to > > first create a working CAN bus setup and then add the tcan to it. > > I have to thank you for mentioning termination, because it turned out > I had not used correct termination at all. How embarrassing! With that > fixed, the transceiver is happy and I have working TX and RX. \o/ > Mostly working RX, anyway. When putting the interface down and then > back up (but allowing a second node to continue attempting TX in the > meantime) I see some blank frames... > > can0 001 [8] 00 01 02 03 04 05 06 07 > can0 001 [8] 00 01 02 03 04 05 06 07 > can0 001 [8] 00 01 02 03 04 05 06 07 > can0 000 [0] > can0 000 [0] > can0 001 [8] 00 01 02 03 04 05 06 07 > can0 001 [8] 00 01 02 03 04 05 06 07 > etc. > > (where the 8-byte frame is what the bus is actually seeing.) Where do you see these blank frames? On the sending rpi with candump? An on the bus (with a second system) you only see the full 8 byte long frames? Use "candump any,0~0,#FFFFFFFF -extA" to get RX/TX annotation. Use "cangen -Ii -L8 -D000102030405060708 -g100 can0" to get increasing CAN-IDs, so you can figure out if a CAN frame got lost. Seems I have to add the TX path to the list of broken things... The mcp251xfd driver can be used as a template for the tcan4x5x driver. regards, 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 |