Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

[Wolfgang Grandegger]

Am 14.03.2017 um 19:08 schrieb Wolfgang Grandegger:
> 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).

Likely the ERR bits are only valid if the BUSERR bit in INTF is set.

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

You could try to set a different bit-rate on the other CAN controller. 
Then try to send or receive messages.

Wolfgang.