Re: RE: [PATCH] can: mcp251xfd: Increase poll timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mer. 10 mai 2023 à 18:18, <Thomas.Kopp@xxxxxxxxxxxxx> a écrit :
>
> > On Wed. 10 May 2023 at 15:30, <Thomas.Kopp@xxxxxxxxxxxxx> wrote:
> > >
> > > > > On 05.05.2023 07:07:03, Thomas.Kopp@xxxxxxxxxxxxx wrote:
> > > > > > > The datasheet "MCP25xxFD Family Reference Manual" says it needs
> > an
> > > > idle
> > > > > > > bus.
> > > > > >
> > > > > > Technically what's needed is an idle condition on the bus as specified
> > > > > > in the ISO. i.e. 11 consecutive sampled recessive bits after a full
> > > > > > frame (if one is currently in transmission).
> > > > >
> > > > > Right. What happens if another CAN frames comes before there are 11
> > > > > consecutive sampled recessive bits? The IFS for CAN is 3 bits?
> > > >
> > > > Not quite. Between the Frames is an IFS that's correct but the IFS consists
> > of
> > > > an Intermission which is 3 bits long + a bus idle condition of 11 bits. Regular
> > > > frames have to wait for the IFS to elapse BUT there's an exception for error
> > > > frames and overload frames. EF may be up to 12 bit, OF are 8 dominant + 8
> > > > recessive bits, browsing through the spec I think only 2 OFs can happen
> > > > consecutively. Adding another 32 bits to the formula should cover this.
> > >
> > > Re-reading the spec again I noticed that the part where I wrote
> > > that there's an "idle condition" after the intermission is
> > > wrong. What follows the intermission is just "bus idle",
> > > defined two paragraphs later as "The period of bus idle may be
> > > of arbitrary length." The 11 recessive bits can be removed from
> > > the formula again. The longest period (under the assumption
> > > there aren't multiple/continuous errors on the bus) will be
> > > Frame + Error Frame (12 bit) + 2 x Overload Frame.
> >           ^^^^^^^^^^^^^^^^^^^^
> >
> > How did you find that a error frame is 12 bits? From section 10.4.4
> > "Specification of EF", I can read:
> >
> >   The EF shall consist of two different fields. The first field
> >   shall be given by the superposition of error flags contributed
> >   from different nodes. The second field shall be the error
> >   delimiter.
> >
> > Then:
> >
> >   Two forms of error flag may be used, the active error flag and
> >   the passive error flag, where
> >
> >    - the active error flag shall consist of 6 consecutive
> >      dominant bits, and
> >
> >    - the passive error flag shall consist of 6 consecutive
> >      recessive bits unless it is overwritten by dominant bits
> >      from other nodes.
> >
> > Finally:
> >
> >   The error delimiter shall consist of 8 recessive bits.
> >
> > So the error frame should be 14 bits (6 + 8), not 12, right?
> That was imprecise, you're right - I meant an Error Flag, not Frame and hence the 8 recessive bits were missing. There's an active error flag + passive error flag though which can be 6 bits long each. In section 10.4.4.2 The total length of this sequence may vary between a minimum of 6 bit and a maximum of 12 bit.

The active error flag and the passive error flag may both occur, but
in that case, they occur as a superposition (c.f. above quotation).
This also means that the passive error flag is seen if and only if all
the nodes send a passive error flag. As long as one node sends an
active error flag, the superposition will hide any other passive error
flag.

So, I think that the error flag is always 6.

> > For the great total, if you want the absolute worst case, you should
> > consider that:
> >
> >   - The error frame may start at any point. For example, you may
> >     observe the first two bits of the intermission and have it
> >     broken by an error frame. It may also appear in the middle of
> >     a data frame. So you may consider cases such as: partial
> >     frame + error frame + intermission + frame + ...
> >
> >   - The overload frame is required to "destroy the fixed form of
> >     the intermission field". So even if not explicitly specified,
> >     I think that overload frame may start after the second
> >     recessive bits of the intermission, e.g. frame + 2 bits of
> >     intermission + overload frame + 2 bits of intermission +
> >     overload frame + full 3 bits intermission
> >
> >   - An error frame or an overload frame may trigger another error
> >     frame if a node does not correctly receive one of the bits in
> >     the fixed form delimiter. The only exception is the last bit
> >     of that delimiter (c.f. section 10.11 "Error detection"
> >     paragraph d) "Form error"). In other words, you can have
> >     the two overload frames, then an error frame, then two
> >     overload frames again.

Correcting myself: that last example was invalid. There are at maximum
two overload frames before the next data or remote frame. So the
presence of an error frame should not reset the overload frame count.

> > This is to say that the worst case scenario is just not something
> > worth consideration.
>
> ACK
> > The assumption that only one error frame occurs is pretty arbitrary. I
> > would suggest making it simpler and simply ignore error and overload
> > frames. As long as frame + intermission works well in empirical tests,
> > I would suggest to stay with that and call it a day.
>
> Correct, that's why I wrote: (under the assumption there aren't multiple/continuous errors on the bus) but I agree that's a pretty arbitrary limit. So I'm fine with changing it to one or two full-sized frames + intermission)

ACK. At the end, you have the hardware, so you should decide what is
the best delay to fix the issue. I just hope that my message was
helpful to simplify the formula.

> Best Regards,
> Thomas




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux