public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: "Ira W. Snyder" <iws@ovro.caltech.edu>
Cc: socketcan-core@lists.berlios.de, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, sameo@linux.intel.com
Subject: Re: [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent CAN	module
Date: Mon, 22 Mar 2010 22:24:08 +0100	[thread overview]
Message-ID: <4BA7DFF8.4060407@grandegger.com> (raw)
In-Reply-To: <20100322205101.GC19327@ovro.caltech.edu>

Ira W. Snyder wrote:
> On Mon, Mar 22, 2010 at 09:28:25PM +0100, Wolfgang Grandegger wrote:
> 
> [ big snip ]
> 
>> You could even add the tx/rx values for each error message (for both,
>> state changes and bus-errors).
>>
> 
> Ok, with that change, I get the following:
> 
> berr-reporting on:
> 
>   can0  20000088  [8] 00 00 80 19 00 00 08 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 10 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 18 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 20 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 28 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 30 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 38 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 40 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 48 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 50 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 58 00   ERRORFRAME
>   can0  20000004  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 60 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 68 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 70 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 78 00   ERRORFRAME
>   can0  20000004  [8] 00 20 00 00 00 00 80 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 80 00   ERRORFRAME
>   can0  20000088  [8] 00 00 80 19 00 00 80 00   ERRORFRAME
> 
> And now lots more of this last frame repeated, until the controller
> decides to stop. Seems fine. It has always done this.
> 
> berr-reporting off:
> 
>   can1  20000004  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
>   can1  20000004  [8] 00 20 00 00 00 00 80 00   ERRORFRAME
> 
> 
> Same as before. Excellent.

Yes, below is some more theory from the AT91 CAN manual, in case you are
interested in technical details.

Wolfgang.

-----------------------------------------------------------------------
o REC: Receive Error Counter
  When a receiver detects an error, REC will be increased by one, except
  when the detected error is a BIT ERROR while sending an ACTIVE ERROR
  FLAG or an OVERLOAD FLAG. When a receiver detects a dominant bit as
  the first bit after sending an ERROR FLAG, REC is increased by 8.
  When a receiver detects a BIT ERROR while sending an ACTIVE ERROR
  FLAG, REC is increased by 8. Any node tolerates up to 7 consecutive
  dominant bits after sending an ACTIVE ERROR FLAG, PASSIVE ERROR FLAG
  or OVERLOAD FLAG. After detecting the 14th consecutive dominant bit
  (in case of an ACTIVE ERROR FLAG or an OVER-LOAD FLAG) or after
  detecting the 8th consecutive dominant bit following a PASSIVE ERROR
  FLAG, and after each sequence of additional eight consecutive dominant
  bits, each receiver increases its REC by 8. After successful reception
  of a message, REC is decreased by 1 if it was between 1 and 127. If
  REC was 0, it stays 0, and if it was greater than 127, then it is set
  to a value between 119 and 127.

o TEC: Transmit Error Counter
  When a transmitter sends an ERROR FLAG, TEC is increased by 8 except
  when:
  - the transmitter is error passive and detects an ACKNOWLEDGMENT ERROR
    because of not detecting a dominant ACK and does not detect a
    dominant bit while sending its PASSIVE ERROR FLAG.
  - the transmitter sends an ERROR FLAG because a STUFF ERROR occurred
    during arbitration and should have been recessive and has been sent
    as recessive but monitored as dominant.
  When a transmitter detects a BIT ERROR while sending an ACTIVE ERROR
  FLAG or an OVERLOAD FLAG, the TEC will be increased by 8.
  Any node tolerates up to 7 consecutive dominant bits after sending an
  ACTIVE ERROR FLAG, PASSIVE ERROR FLAG or OVERLOAD FLAG. After
  detecting the 14th consecutive dominant bit (in case of an ACTIVE
  ERROR FLAG or an OVERLOAD FLAG) or after detecting the 8th consecutive
  dominant bit following a PASSIVE ERROR FLAG, and after each
  sequence of additional eight consecutive dominant bits every
  transmitter increases its TEC by 8. After a successful transmission
  the TEC is decreased by 1 unless it was already 0.


  reply	other threads:[~2010-03-22 21:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18 16:38 [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent CAN module Ira W. Snyder
2010-03-19  9:01 ` Wolfgang Grandegger
2010-03-19 15:19   ` Ira W. Snyder
2010-03-19 15:45     ` Wolfgang Grandegger
2010-03-19 20:03       ` Ira W. Snyder
2010-03-19 20:13         ` Wolfgang Grandegger
2010-03-19 21:52           ` Ira W. Snyder
2010-03-20  7:55             ` Wolfgang Grandegger
2010-03-22 15:53               ` Ira W. Snyder
2010-03-22 19:17                 ` Wolfgang Grandegger
2010-03-22 19:23                   ` Wolfgang Grandegger
2010-03-22 20:12                     ` Ira W. Snyder
2010-03-22 20:10                   ` Ira W. Snyder
2010-03-22 20:28                     ` Wolfgang Grandegger
2010-03-22 20:51                       ` Ira W. Snyder
2010-03-22 21:24                         ` Wolfgang Grandegger [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-03-29 16:58 Ira W. Snyder
2010-03-30  8:14 ` Wolfgang Grandegger
2010-03-31  6:46   ` David Miller
2010-04-01 20:03 ` Andrew Morton
2010-04-02  0:43   ` Ira W. Snyder
2010-03-02 21:22 [PATCH 0/3 RFCv4] add support for Janz MODULbus devices Ira W. Snyder
2010-03-02 21:22 ` [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent CAN module Ira W. Snyder
2010-03-17 19:33   ` Ira W. Snyder
2010-03-18  8:36     ` Wolfgang Grandegger
2010-03-18 15:19       ` Ira W. Snyder
2010-03-18 16:06         ` Wolfgang Grandegger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA7DFF8.4060407@grandegger.com \
    --to=wg@grandegger.com \
    --cc=iws@ovro.caltech.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=socketcan-core@lists.berlios.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox