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

From: <Thomas.Kopp@microchip.com>
To: <mailhol.vincent@wanadoo.fr>, <mkl@pengutronix.de>
Cc: <kayoub5@live.com>, <linux-can@vger.kernel.org>
Subject: RE: mcp251xfd receiving non ACKed frames (was: Re: More flags for logging)
Date: Tue, 4 May 2021 12:53:16 +0000	[thread overview]
Message-ID: <DM6PR11MB42835BBA69260C24BEAECA2EFB5A9@DM6PR11MB4283.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAMZ6RqK1ZnygjiZ=sXf7zBSodhL1oS1GZz1rcu=92aQ_A-sFew@mail.gmail.com>

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.

Thomas