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

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

 



> > > 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.

I think if one node detects a bit error (that's not on the bus but inside the receiving node) on the second bit of the intermission it will start sending the 6 dominant bits, starting on the third bit of the intermission. Now, according to 10.4.2.2 " A node sampling a dominant bit during its suspend transmission time or at the third bit of intermission shall accept it as SOF.", treating the next 5 dominant bits as part of the ID of a new DF and only then sending its own error flag, giving a total of 12 dominant bits followed by 8 recessive bits EF delimiter etc. Am I missing something here? For this (I believe worst case when only considering 1 EF you could deduct one bittime - the third bit in the intermission)

> > > 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.

I agree a simple formula will be the best way forward as the rest is academic only anyway.

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