Re: mcp251xfd receiving non ACKed frames (was: Re: More flags for logging)

From: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
To: Thomas.Kopp@microchip.com
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
	Ayoub Kaanich <kayoub5@live.com>,
	linux-can <linux-can@vger.kernel.org>
Subject: Re: mcp251xfd receiving non ACKed frames (was: Re: More flags for logging)
Date: Tue, 4 May 2021 23:26:47 +0900	[thread overview]
Message-ID: <CAMZ6RqJt0Ai6Uk2ZsOTqD_C1Cw2FTNOg088RXp7UsgHKcAkE2w@mail.gmail.com> (raw)
In-Reply-To: <DM6PR11MB42835BBA69260C24BEAECA2EFB5A9@DM6PR11MB4283.namprd11.prod.outlook.com>

On Tue. 4 Mai 2021 à 21:53, <Thomas.Kopp@microchip.com> 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