mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: Akshay Bhat <akshay.bhat@timesys.com>, mkl@pengutronix.de
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Akshay Bhat <nodeax@gmail.com>
Subject: Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver
Date: Tue, 14 Mar 2017 19:08:19 +0100	[thread overview]
Message-ID: <41439729-42d0-d883-2801-2d3607f2aeab@grandegger.com> (raw)
In-Reply-To: <3dbf8748-9d04-0f21-0e95-448d7a72e7d5@timesys.com>

Hello Akshay,

Am 14.03.2017 um 17:20 schrieb Akshay Bhat:
>
> Hi Wolfgang,
>
> On 03/14/2017 08:11 AM, Wolfgang Grandegger wrote:
>> ... snip ...
>>>> A few other things to check:
>>>>
>>>> Run "cangen" and monitor the message with "candump -e any,0:0,#FFFFFFF".
>>>> Then 1) disconnect the cable or 2) short-circuit CAN low and high at the
>>>> connector. You should see error messages. After reconnection or removing
>>>> the short-circuit (and bus-off recovery) the state should go back to
>>>> "active".
>>>>
>>>
>>> With the above sequence, candump reports "ERRORFRAME" with
>>> protocol-violation{{}{acknowledge-slot}}, bus-error. On re-connecting
>>> the cable the can state goes back to ACTIVE and I see the messages that
>>> were in the queue being sent.
>>
>> Do you get the ACK error also with berr-reporting off? Would be nice if
>> you could show a candump log here.
>>
>
> Below is a log for disconnecting and re-connecting CAN cable scenario:
> (Note this is on a 4.1.18 kernel with RT patch)
>
> root@imx6qrom5420b1:~# ip link set can0 up type can bitrate 1000000
> berr-reporting on
> root@imx6qrom5420b1:~# candump -e any,0:0,#FFFFFFF &

Please add "-td" ...

> [1] 768
> root@imx6qrom5420b1:~# cangen can0

and "-i" here.

>   can0  21C   [8]  35 98 C0 7A 95 03 E6 2A
>   can0  6E6   [1]  F2
>   can0  5C7   [2]  42 50
>   can0  57C   [8]  83 7A E4 0C 03 8B 90 45
>   can0  55C   [8]  B9 74 87 52 D8 F4 64 04
>   can0  014   [8]  28 CB 96 57 3B 80 67 4F
>   can0  6AF   [1]  35
>   can0  51E   [8]  B6 C8 6C 1D 3A 87 ED 2E
>   can0  527   [8]  D0 8A D3 59 0E 34 40 78
>   can0  30C   [2]  6A 12
>   can0  145   [8]  CB 6E FF 55 C1 BE C3 22
>   can0  5A5   [8]  C4 49 54 68 02 63 F9 35
>   can0  0BA   [8]  DA 57 5E 3A CE 88 20 1C
>   can0  516   [2]  09 09
>   can0  743   [8]  7C 4D 25 47 61 4C 56 3D
>   can0  31D   [2]  9C D3
>   can0  71E   [8]  53 7C 97 2A 2A F2 9F 56
>   can0  52E   [8]  FE DA 2D 51 73 96 DF 79
> /////disconnect cable
>   can0  20000088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
> 	protocol-violation{{}{acknowledge-slot}}
> 	bus-error
> 	error-counter-tx-rx{{40}{0}}
>   can0  20000088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
> 	protocol-violation{{}{acknowledge-slot}}
> 	bus-error
> 	error-counter-tx-rx{{88}{0}}
>   can0  20000088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
> 	protocol-violation{{}{acknowledge-slot}}
> 	bus-error
> 	error-counter-tx-rx{{128}{0}}

TX error warning is missing.

>   can0  2000008C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
> 	controller-problem{tx-error-passive}
> 	protocol-violation{{}{acknowledge-slot}}
> 	bus-error
> 	error-counter-tx-rx{{128}{0}}

Here "tx-error-passiv" is packed with a bus error. What I'm looking for 
are state change messages similar to:

    can0  20000204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
         controller-problem{tx-error-warning}
         state-change{tx-error-warning}
         error-counter-tx-rx{{96}{0}}
    can0  20000204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
         controller-problem{tx-error-passive}
         state-change{tx-error-passive}
         error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".

> write: No buffer space available
> root@imx6qrom5420b1:~# ip -s -d link show can0
> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> mode DEFAULT group default qlen 10
>     link/can  promiscuity 0
>     can <BERR-REPORTING> state ERROR-PASSIVE (berr-counter tx 128 rx 0)
> restart-ms 0
> 	  bitrate 1000000 sample-point 0.750
> 	  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
> 	  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
> 	  clock 16000000
> 	  re-started bus-errors arbit-lost error-warn error-pass bus-off
> 	  0          6          0          1          1          0

The error warning and passive counter increased , though. Also the bus 
error should come in at a rather hight rate. Looking to the code, maybe
you need to test STATF to check for state changes (and not ERR).

>     RX: bytes  packets  errors  dropped overrun mcast
>     0          0        6       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     106        18       0       0       0       0
> root@imx6qrom5420b1:~#
> /////re-connect cable
>   can0  169   [8]  35 55 A3 1C 0F 47 2E 5B
>   can0  318   [8]  11 AA 27 11 D2 1B CE 34
>   can0  577   [8]  A0 A4 EE 50 8D A2 E1 3E
>   can0  4ED   [8]  52 96 17 7E 31 FC 7D 7C
>   can0  2E7   [8]  92 48 D4 39 05 1E 9F 50
>   can0  200   [8]  4A 66 F6 02 1E 71 8E 26
>   can0  29A   [8]  49 63 2E 7D C9 77 85 7A
>   can0  15A   [7]  3C 0E 65 74 C3 62 80
>   can0  011   [1]  D2
>   can0  26B   [3]  FC D6 68
>   can0  5CE   [8]  6F 02 B5 14 BC 7A D7 02
>
> root@imx6qrom5420b1:~# ip -s -d link show can0
> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> mode DEFAULT group default qlen 10
>     link/can  promiscuity 0
>     can <BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 117 rx 0)
> restart-ms 0
> 	  bitrate 1000000 sample-point 0.750
> 	  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
> 	  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
> 	  clock 16000000
> 	  re-started bus-errors arbit-lost error-warn error-pass bus-off
> 	  0          7          0          1          1          0
>     RX: bytes  packets  errors  dropped overrun mcast
>     0          0        7       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     181        29       0       0       0       0
>
>
> //Reboot the board and test with bus error reporting off
>
> root@imx6qrom5420b1:~# ip link set can0 up type can bitrate 1000000
> berr-reporting off
> root@imx6qrom5420b1:~# candump -e any,0:0,#FFFFFFF &
> [1] 782
> root@imx6qrom5420b1:~# cangen can0
>   can0  1FA   [3]  C9 FE C2
>   can0  3E2   [5]  85 37 03 5B 6F
>   can0  289   [8]  A4 F6 BF 4A 3F 70 65 1B
>   can0  12D   [8]  B2 72 10 33 AB B4 68 64
>   can0  054   [2]  01 D7
>   can0  4A6   [8]  29 7D 76 56 CA C1 60 00
>   can0  768   [8]  97 3D 92 08 61 C1 D9 03
>   can0  098   [6]  A4 A8 5A 60 92 1A
>   can0  3C9   [8]  71 78 0D 25 AB 27 8B 51
> /////disconnect cable
> write: No buffer space available
> root@imx6qrom5420b1:~# ip -s -d link show can0
> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> mode DEFAULT group default qlen 10
>     link/can  promiscuity 0
>     can state ERROR-ACTIVE (berr-counter tx 128 rx 0) restart-ms 0
> 	  bitrate 1000000 sample-point 0.750
> 	  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
> 	  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
> 	  clock 16000000
> 	  re-started bus-errors arbit-lost error-warn error-pass bus-off
> 	  0          0          0          0          0          0
>     RX: bytes  packets  errors  dropped overrun mcast
>     0          0        0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     56         9        0       0       0       0
> root@imx6qrom5420b1:~#
> /////re-connect cable
> can0  20000088   [8]  00 00 00 19 00 00 7F 00   ERRORFRAME
> 	protocol-violation{{}{acknowledge-slot}}
> 	bus-error
> 	error-counter-tx-rx{{127}{0}}
>   can0  553   [6]  1A E4 60 6B DC 07
>   can0  7E3   [8]  1C 78 95 6E 10 81 AA 40
>   can0  20C   [8]  BB 35 13 25 60 0A 56 57
>   can0  1D0   [8]  48 4A 39 64 76 E6 57 08
>   can0  43A   [1]  40
>   can0  2CF   [7]  03 45 5E 0F 67 33 4C
>   can0  1CD   [8]  F9 4D AB 1D 96 A5 67 0E
>   can0  515   [8]  41 CD F2 5F 68 92 43 16
>   can0  661   [8]  45 9A 73 69 45 EE 8B 42
>   can0  41B   [1]  55
>   can0  52F   [1]  87

After some more messages there should be also:

     can0  20000200  [8] 00 40 00 00 00 00 5F 00   ERRORFRAME
         state-change{back-to-error-active}
         error-counter-tx-rx{{95}{0}}

For each message sent, the error counter decreases by 8.


>
> root@imx6qrom5420b1:~# ip -s -d link show can0
> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> mode DEFAULT group default qlen 10
>     link/can  promiscuity 0
>     can state ERROR-ACTIVE (berr-counter tx 117 rx 0) restart-ms 0
> 	  bitrate 1000000 sample-point 0.750
> 	  tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
> 	  hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
> 	  clock 16000000
> 	  re-started bus-errors arbit-lost error-warn error-pass bus-off
> 	  0          1          0          0          0          0

Strange, some counters got lost.

>     RX: bytes  packets  errors  dropped overrun mcast
>     0          0        1       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     120        20       0       0       0       0
>
>
>> Also, any error message should show the bus error counts in data[7,8]:
>>
>> http://lxr.free-electrons.com/source/drivers/net/can/sja1000/sja1000.c#L408
>>
>
> I can add this in v4 version of the patch (Above log has this patch
> applied).

Looks good.

>> And please check bus-off as well (short-circuiting CAN low and high).
>>
>
> I have not been able to check the bus-off condition by (short-circuiting
> CAN low and high). The tec error count remains at 128 when I short the
> CAN low and high pins and the status never goes BUSOFF.

You also need to send a message and the short-circuit should be at the 
connector of the sending host. What tranceiver is used? Do you know?

Wolfgang.

  reply	other threads:[~2017-03-14 18:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17 19:22 [PATCH v2 1/2] can: holt_hi311x: document device tree bindings Akshay Bhat
2017-01-17 19:22 ` [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver Akshay Bhat
2017-03-07 15:31   ` Akshay Bhat
2017-03-09  9:59     ` Wolfgang Grandegger
2017-03-09 12:34       ` Akshay Bhat
2017-03-09 14:45         ` Wolfgang Grandegger
2017-03-09 15:28           ` Akshay Bhat
2017-03-09 17:36   ` Wolfgang Grandegger
2017-03-13 15:38     ` Akshay Bhat
2017-03-14 12:11       ` Wolfgang Grandegger
2017-03-14 16:20         ` Akshay Bhat
2017-03-14 18:08           ` Wolfgang Grandegger [this message]
2017-03-14 21:23             ` Wolfgang Grandegger
2017-03-15  4:44             ` Akshay Bhat
2017-03-15  7:19               ` Wolfgang Grandegger
2017-03-15  9:42               ` Wolfgang Grandegger
2017-03-16 17:06                 ` Akshay Bhat
2017-03-16 20:02                   ` Wolfgang Grandegger
2017-03-16 22:29                     ` Akshay Bhat
2017-03-17  7:39                       ` Wolfgang Grandegger
2017-03-17  8:17                         ` Wolfgang Grandegger
2017-03-17 16:00                         ` Akshay Bhat
2017-03-17 17:04                           ` Wolfgang Grandegger
2017-03-17 18:28                             ` Akshay Bhat
2017-03-18 12:30                               ` 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=41439729-42d0-d883-2801-2d3607f2aeab@grandegger.com \
    --to=wg@grandegger.com \
    --cc=akshay.bhat@timesys.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=nodeax@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®