lkml.org 
[lkml]   [2017]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver
    From
    Date
    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.

    \
     
     \ /
      Last update: 2017-03-14 22:25    [W:3.418 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site