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

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

 



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?



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.

This is to say that the worst case scenario is just not something
worth consideration.

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.



[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