All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Evans <tom_usenet@optusnet.com.au>
To: Julien Pilet <julien@anemomind.com>,
	Wolfgang Grandegger <wg@grandegger.com>
Cc: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: Bad reading from mcp2515 with j1939
Date: Mon, 18 Apr 2016 14:29:43 +1000	[thread overview]
Message-ID: <571462B7.8020905@optusnet.com.au> (raw)
In-Reply-To: <86B92DF4-DB93-457E-8BFB-7FA1BBBE2B4D@anemomind.com>

On 16/04/16 02:25, Julien Pilet wrote:
> Hi,
>
> Thanks a lot for your help, I found the error.
 > There was a resistor that was not supposed to be
 > there (120ohms between CANH and CANL).
 > Removing it solved the problem.

Do you mean there was an EXTRA terminating resistor that you removed? The CAN 
bus is specified to have two 120 ohm resistors, normally situated as close to 
the ends of the cable as reasonably possible. Check the diagrams and read the 
"Physical Layer" part of the following for details:

https://en.wikipedia.org/wiki/CAN_bus#Layers

A CAN bus should be able to tolerate three 120 ohm terminators. The On Semi 
AMIS-42770 is specified to work with a minimum termination resistance of 42.5 
ohms. If the bus wiring is high resistance, there are bad connections, or if 
someone has added series resistors or inductors between the transceivers and 
the bus then it might not even work with two terminators. You should check for 
this.

I was very surprised that it was able to receive bad data. There's a 15-bit 
checksum on the data. The only way to have bad data is to have a two-bit or a 
three-bit error that generates the same checksum, or a data bit error and a 
checksum bit error that cancel each other out.

That is extremely unlikely as normally a CAN bus has multiple devices, and 
they're all checking all packets on the wire, all the time. If ANY of them 
detect an error, then they report it back to the wire and that invalidates the 
message, forcing a retransmit.

Do you have only the one transmitter and the one receiver on that bus? If 
there's only the one receiver then it is more likely that a corrupted or noisy 
signal could sneak through bad data. The sensitivity to "every even byte over 
0x80" implies a specific data pattern, stuffing bit and checksum sensitivity.

Do the baud rates match exactly or are they around 1% out? That can cause 
problems related to runs of zeros and stuff bits.

You should monitor TEC and REC if they're available through the interface and 
drivers. It is a boat. What is the common grounding like? You might be getting 
ground shifts between the devices that could be making things worse.

Tom


  parent reply	other threads:[~2016-04-18  4:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15  9:54 Bad reading from mcp2515 with j1939 Julien Pilet
2016-04-15 10:19 ` Kurt Van Dijck
2016-04-15 13:02   ` Julien Pilet
2016-04-15 14:52     ` Wolfgang Grandegger
2016-04-15 16:25       ` Julien Pilet
2016-04-15 16:34         ` Wolfgang Grandegger
2016-04-18  5:48           ` Wolfgang Grandegger
2016-04-18  4:29         ` Tom Evans [this message]
2016-04-15 13:07 ` Ramesh Shanmugasundaram

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=571462B7.8020905@optusnet.com.au \
    --to=tom_usenet@optusnet.com.au \
    --cc=dev.kurt@vandijck-laurijssen.be \
    --cc=julien@anemomind.com \
    --cc=linux-can@vger.kernel.org \
    --cc=wg@grandegger.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.