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

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

 




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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux