On Thursday, February 16, 2023 10:10 AM, Oliver Hartkopp wrote: > On 2/16/23 16:34, Hartley Sweeten wrote: >> On Thursday, February 16, 2023 4:19 AM, Michal Simek wrote: >>>> On 2/7/23 21:45, Oliver Hartkopp wrote: >>>> Hi xilinx_can maintainers, >>>>> >>>>> Hartley Sweeten reported a bug when sending RTR frames with the >>>>> xilinx_can driver here: >>>>> >>>>> https://github.com/linux-can/can-utils/issues/405# >>>>> >>>>> The problem: When sending a single RTR frame (e.g. with 'cansend >>>>> can0 >>>>> 001#R') nothing happens. >>>>> >>>>> Only after sending a *second* RTR frame with 'cansend can0 001#R' >>>>> the two (pending) RTR-frames are sent directly after each other. >>>>> >>>>> This faulty behavior of RTR frame sending is independent of the >>>>> time gap between the two cansend attempts. >>> >>> I read that thread and I am missing details about Zynq board. >>> Are you using any custom zynq board or any xilinx standard evaluation board? >> >> The system is a Trenz TE0720 SoM on a custom carrier board. >> >> CAN0 is routed to EMIO. >> Tx -> pin E16 (LVCMOS33) >> Rx -> pin F16 (LVCMOS33) >> >> The CAN implementation on the carrier board is like on the ZC702 (TXS0104 buffer / TJA1040T transceiver). >> Just some more info in case it helps. I have a logic analyzer connected to the Tx/Rx signals going to the TJA1040T transceiver and an oscilloscope connected to the CANH/L signals. If I try doing the following: $ cansend can0 001#R $ cansend can0 003#R I only see the 001#R message and response on the logic analyzer and oscilloscope. The 003#R message is never sent. But non RTR messages are always sent immediately. Hartley
