[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd33e1b365502ec0cb3b5bee6dc4fb61@agner.ch>
Date: Mon, 04 Aug 2014 15:43:06 +0200
From: Stefan Agner <stefan@...er.ch>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: shawn.guo@...escale.com, kernel@...gutronix.de,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-can@...r.kernel.org
Subject: Re: [PATCH v3 4/4] can: flexcan: add vf610 support for FlexCAN
Am 2014-07-30 13:47, schrieb Marc Kleine-Budde:
> On 07/29/2014 09:29 AM, Stefan Agner wrote:
>> Am 2014-07-28 18:28, schrieb Marc Kleine-Budde:
>>> On 07/28/2014 06:20 PM, Stefan Agner wrote:
>>>> I'm not sure whether you really want to keep the FLEXCAN_CTRL_ERR_STATE
>>>> commented out...
>>>
>>> No, please remove this change and redo the test.
>>>
>>
>> Ok, removed that change and did the tests again:
>>
>> == Wrong Bitrate test
>>
>> [ 146.485022] flexcan 40020000.flexcan can0: bitrate error 0.7%
>> [ 148.401793] flexcan 40020000.flexcan can0: writing ctrl=0x17092001
>> [ 148.408263] flexcan 40020000.flexcan can0: flexcan_set_bittiming:
>> mcr=0x5980000f ctrl=0x17092001
>> [ 148.408298] flexcan 40020000.flexcan can0: flexcan_chip_start:
>> writing mcr=0x79a20208
>> [ 148.408328] flexcan 40020000.flexcan can0: flexcan_chip_start:
>> writing ctrl=0x1709ac51
>> [ 148.414373] flexcan 40020000.flexcan can0: flexcan_chip_start:
>> reading mcr=0x60a20208 ctrl=0x1709ac51
>> ^---- Initialization
>> [ 152.968685] flexcan_irq, esr=00040080
>> [ 152.972386] flexcan_irq, ctrl=1709ac51
>> [ 155.488623] flexcan_irq, esr=00040080
>> [ 155.492326] flexcan_irq, ctrl=1709ac51
>> ^---- Two messages with right bitrate
>> [ 171.014124] flexcan_irq, esr=00058d0a
>> [ 171.017823] flexcan_irq, ctrl=1709ac51
>> ^---- One message with wrong bitrate
>> [ 171.021631] flexcan 40020000.flexcan can0: Error Warning IRQ
>> [ 171.021660] flexcan 40020000.flexcan can0: Error Passive IRQ
>
> Thanks for the test, so far looks promising :) With this setup the other
> CAN node repeats the CAN frame until it's ACKed. Because there is no
> node with a compatible bitrate, there is no ACking CAN node.
>
> Can you add a third CAN node to the network. The second and third node
> should use the same bitrate, while your vf610 uses a different one. With
> the new setup it should take more than one frame until the vf610 goes
> into error warning and even more frames to error passive. This way we
> can see it the error warning interrupt is connected or not. The error
> counters should increase with each "wrong" bitrate frame it sees, you
> can check with:
>
> ip -details link show can0
>
> The output looks like this:
>
>> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 10
>> link/can
>> can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
> ^^^^^^^^^^^^^^^^^^^^^^
>> bitrate 1000000 sample-point 0.750
>> tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
>> sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>> clock 8000000
>
> When one of the berr-counter crosses 96 (and stays below 128) a warning
> interrupt should be generated.
Ok, created this setup, could successfully communicate with all three
nodes. I then set the Vybrid to half of the bitrate. When I send a frame
from Vybrid, the berr-counter tx immediately ends up at 128 and the
device is in ERROR-PASSIVE:
root@...ibri-vf:~# ip -details link show can1
3: can1: <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 0 rx 0) restart-ms 0
bitrate 124990 sample-point 0.739
tq 347 prop-seg 8 phase-seg1 8 phase-seg2 6 sjw 1
flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp-inc 1
clock 83368421
root@...ibri-vf:~# cansend can1 1F334455#1122334455667788
interface = can1, family = 29, type = 3, proto = 1
root@...ibri-vf:~# [ 818.886664] flexcan_irq, esr=00062242
[ 818.890365] flexcan_irq, ctrl=1c3dac57
root@...ibri-vf:~# ip -details link show can1
3: can1: <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-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0
bitrate 124990 sample-point 0.739
tq 347 prop-seg 8 phase-seg1 8 phase-seg2 6 sjw 1
flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp-inc 1
clock 83368421
When I send the frames from another device on the bus, I can see the rx
count incrementing by one on each frame I send. As you expected, the
device changes to ERROR-WARNING when crossing the 96 frame boundary:
root@...ibri-vf:~# ip -details link show can1
3: can1: <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 0 rx 92) restart-ms 0
bitrate 124990 sample-point 0.739
tq 347 prop-seg 8 phase-seg1 8 phase-seg2 6 sjw 1
flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp-inc 1
clock 83368421
root@...ibri-vf:~# [ 448.331150] flexcan_irq, esr=0005050a
[ 448.334851] flexcan_irq, ctrl=1c3dac57
ip -details link show can1
3: can1: <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-WARNING (berr-counter tx 0 rx 102) restart-ms 0
bitrate 124990 sample-point 0.739
tq 347 prop-seg 8 phase-seg1 8 phase-seg2 6 sjw 1
flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp-inc 1
clock 83368421
However, once reaching 128, I don't get another interrupt and the device
stays in ERROR-WARNING:
3: can1: <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-WARNING (berr-counter tx 0 rx 128) restart-ms 0
bitrate 124990 sample-point 0.739
tq 347 prop-seg 8 phase-seg1 8 phase-seg2 6 sjw 1
flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp-inc 1
clock 83368421
Is this the expected behavior on receive?
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists