From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFFEAC433B4 for ; Tue, 4 May 2021 14:27:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 82AEC610A5 for ; Tue, 4 May 2021 14:27:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230246AbhEDO1y convert rfc822-to-8bit (ORCPT ); Tue, 4 May 2021 10:27:54 -0400 Received: from mail-yb1-f180.google.com ([209.85.219.180]:34467 "EHLO mail-yb1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230213AbhEDO1y (ORCPT ); Tue, 4 May 2021 10:27:54 -0400 Received: by mail-yb1-f180.google.com with SMTP id v188so2292030ybe.1 for ; Tue, 04 May 2021 07:26:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IpRRiO4mlKOBNvzXatg5SGAvdvrXnQ0q9E05iS4O6IA=; b=jkgHjfnDYHEXz9oMXE9Sjcr9+3hrh6Lbpv5ffvu8tbQl6edq531FAdIx5mPqbU8u82 Trr43pVIZcdNDBH8pQiEECZyRL3cLyzrr6TdiBBcxjJFdv6SoPd7m2E+EsQdTUkSHobK IcETKuWC+EchWcy0jkAWbMPAzn78kZoybPPRqMfDkWieTnA7ocGSx3TOC+Q05BnYkrkc DeiaONtnhCD1p0mvSyKnwwfrqPVwkxNXPNPSjs10gjnrhB+Jv8Y08js8vbc03yn3iHp8 H/2idCQ1J8WVNohcUiL8XRoN7N4RzfprsZZeWulJQ2bDUFz2HiKIt3Pm0wj7vm3Dvoba DI7Q== X-Gm-Message-State: AOAM531J71b0w64KVjkI1My8nKZepu1ju6CyJHjuARChIqeS31UQhnQx dLdOG7RBkSBFbEhVLmYzflWTIqYbSCIuek3oHzc= X-Google-Smtp-Source: ABdhPJz0jjdIpQvRBKmfVz1fnkU5svZpvXozUbUCnabqOidus5UeiTT2L0sqoi2G3QRmHu4EuxGAwFGUCBPhIZxSMwo= X-Received: by 2002:a25:be09:: with SMTP id h9mr35665286ybk.239.1620138419115; Tue, 04 May 2021 07:26:59 -0700 (PDT) MIME-Version: 1.0 References: <20210503100246.n7uu437kbabdzu7m@pengutronix.de> <20210503100810.cacbmdfmpjipgoka@pengutronix.de> <20210503154749.q3nrfjveixsqp3uj@pengutronix.de> <20210504074834.tki7gzr6wz2le6o3@pengutronix.de> In-Reply-To: From: Vincent MAILHOL Date: Tue, 4 May 2021 23:26:47 +0900 Message-ID: Subject: Re: mcp251xfd receiving non ACKed frames (was: Re: More flags for logging) To: Thomas.Kopp@microchip.com Cc: Marc Kleine-Budde , Ayoub Kaanich , linux-can Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org On Tue. 4 Mai 2021 à 21:53, wrote: > Hi All, > > > I guess that above error flags are the consequence of the > > interferences on the bus while unplugging the candlelight. Those > > are probably not relevant to our specific topic. > > > > > | (2021-05-04 09:05:02.100540) mcp251xfd0 RX - - 222 [8] 4D 00 00 00 00 > > 00 00 00 > > > | (2021-05-04 09:05:02.100570) mcp251xfd0 RX - - 222 [8] 4D 00 00 00 00 > > 00 00 00 > > > | (2021-05-04 09:05:02.100583) mcp251xfd0 RX - - 222 [8] 4D 00 00 00 00 > > 00 00 00 > > > | (2021-05-04 09:05:02.100593) mcp251xfd0 RX - - 222 [8] 4D 00 00 00 00 > > 00 00 00 > > > | (2021-05-04 09:05:02.101326) mcp251xfd0 RX - - 222 [8] 4D 00 00 00 00 > > 00 00 00 > > > > Could be, would be worth to check that one a scope. From what I've seen so far the Bus looks clean without disconnecting nodes. > > > > Second, the receiver behaviour when receiving an non-ACKed frame > > is actually unspecified. As mentioned before, non-ACKed frames > > should be immediately followed by an ACK error flag. Here, the > > receiving nodes are facing a situation which should never > > occur. The mcp2518fd decides to register the frame as received > > and the flexcan decides to not register the frame. I think that > > both behaviors are actually fine: with the lack of specification, > > the implementation is free to decide how to handle this side > > case. > > I'd say it is actually defined. ISO 11989-1:2015 states the following in chapter 10.4 Bus monitoring > "Optionally, CAN implementations may provide the bus monitoring mode, where they shall be able to > receive valid DFs and valid RFs, but it sends only recessive bits on the CAN network and does not start > a transmission. If the MAC sub-layer is required to send a dominant bit (ACK bit, overload flag, active > error flag), the bit shall be rerouted internally so that the MAC sub-layer monitors this dominant bit, > although the CAN network may remain in recessive state." > > Looking at the MCAN manual here: https://github.com/linux-can/can-doc/blob/master/m_can/mcan_users_manual_v330.pdf > > There's a similar description including a picture showing the TX signal being "connected" internally to the RX path to generate the Ack internally. Thanks for pointing this out. You are right and I completely missed that paragraph of the ISO. So this perfectly explains the behaviour of the mcp251xfd0. It also means that the ACK flag is set by the transmitter so there is indeed no way to differentiate if the frame was indeed ACKed or not by the other nodes. Concerning the flexcan it is not following the standard. Even if the monitor mode is optional, once it is implemented, it should behave as stated in chapter 10.4. However, this still does not explain why the Peak does not generate the ACK error flag. Also, the ISO says that in monitoring mode, the controller "does not start a transmission". So it also seems like a violation of the standard that Peak devices are able to transmit frames while being in monitor mode. Yours sincerely, Vincent