Hello Joe,
Am 21.06.2018 um 14:20 schrieb Joe Burmeister:
> Hi Wolfgang,
>
> On 21/06/18 13:01, Wolfgang Grandegger wrote:
>
> <snip>
>>> Is it a C_CAN or D_CAN controller? On D_CAN, this register is self
>> Most probably it a D_CAN controller:
>>
>> { .compatible = "ti,am3352-d_can", .data = &am3352_dcan_drvdata },
>>
>>> clearing. You need to be careful reading that register.
>> I would add a "pr_info("%s: sts=%#x\n", __func__, curr);" right after
>> "curr = priv->read_reg(priv, C_CAN_STS_REG);" in "c_can_poll)".
>
> I was doing that at first, but it took me awhile to work out that the
> reason I wasn't seeing the bus off was because "c_can_poll" was never
> been called with it.
>
>>
>> In case of trouble you see:
>>
>> can0 20000004 [8] 00 04 00 00 00 00 00 79 ERRORFRAME
>> can0 20000004 [8] 00 10 00 00 00 00 00 79 ERRORFRAME
>>
>> The TX error counter is the same for both messages. For error passive it
>> should be higher, hmm. When the system hangs, what does the following
>> command report:
>>
>> $ ip -d -s link show canX
>
> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode
> DEFAULT group default qlen 10
> link/can promiscuity 0
> can state ERROR-PASSIVE (berr-counter tx 248 rx 121) restart-ms 500
> bitrate 500000 sample-point 0.875
> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
> clock 24000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 2 0 0 5 5 2
> numtxqueues 0 numrxqueues 0
> RX: bytes packets errors dropped overrun mcast
> 39840 4980 0 2 0 0
> TX: bytes packets errors dropped carrier collsns
> 39728 4966 0 4 0 0
>
>
> It all looks fine, but you never see and CAN traffic in or out in
> candump, including what you send manually with cansend.
>
> I think before any I do any other fix, I need to get control of the
> status register clearing.
> But I'm going to have to surrender the hardware soon for people working
> on other issues.
Looking to the code, I see a problem with reading the status register
(C_CAN_STS_REG). It should *only* be read if bit 15 of the interrupt
status register (C_CAN_INT_REG) is set/pending. According to the manual,
reading the status register will also clear the bit in C_CAN_INT_REG.
This could explain lost (bus-off) status interrupts and also the strange
messages I mentioned above.
Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
