Re: [PATCH v2 1/4] can: dev: Consolidate and unify state change handling.

[Wolfgang Grandegger <wg@grandegger.com>]

On Thu, 23 Oct 2014 12:50:20 +0000, Andri Yngvason
<andri.yngvason@marel.com> wrote:
> On mið 22.okt 2014 18:42, Wolfgang Grandegger wrote:
>> On 10/22/2014 06:32 PM, Andri Yngvason wrote:
...
>>> The data sheet says this about EPI:
>>>     set; this bit is set whenever the CAN controller has
>>>     reached the error passive status (at least one
>>>     error counter exceeds the protocol-defined level of
>>>     127) or if the CAN controller is in the error passive
>>>     status and enters the error active status again and
>>>     the EPIE bit is set within the interrupt enable
>>>     register
>>>
>>> I'm a little bit concerned that it actually says that EPI is set on
>>> "error passive"
>>> and "error passive to error active". However, the log says that
>>> txerr=127 on
>>> that second interrupt. It makes more sense for it to be "error
>>> warning". Might
>>> this be a error in the datasheet?
>> IIRC, the CAN standard only knows error active and error passive.
>> Various vendors added the warning level where the level is sometimes
>> even programmable.
> Yes, this makes sense. The manual doesn't even say that the "warning
> level" is a
> state.
...
>>>  (000.053403)  can0  5B1   [5]  D1 D1 BB 7C DF
>>>  (000.146664)  can0  506   [8]  2C 6E 9C 77 5E F1 AE 2D
>>>  (000.053628)  can0  488   [8]  FF C8 AC 26 43 C5 AF 11
>>>  (000.146428)  can0  5AD   [8]  C1 31 BD 1B 6B 8D 34 13
>>>  (000.053112)  can0  658   [0]
>>>  (000.171131)  can0  20000004   [8]  00 08 00 00 00 00 60 00  
>>>  ERRORFRAME
>>>     controller-problem{tx-error-warning}
>>>     error-counter-tx-rx{{96}{0}}
>>>  (000.013841)  can0  20000004   [8]  00 20 00 00 00 00 80 00  
>>>  ERRORFRAME
>>>     controller-problem{tx-error-passive}
>>>     error-counter-tx-rx{{128}{0}}
>>>  (004.433642)  can0  20000002   [8]  04 00 00 00 00 00 00 00  
>>>  ERRORFRAME
>>>     lost-arbitration{at bit 4}
>>>  (000.014785)  can0  20000002   [8]  02 00 00 00 00 00 00 00  
>>>  ERRORFRAME
>>>     lost-arbitration{at bit 2}
>>>  (000.012565)  can0  20000002   [8]  02 00 00 00 00 00 00 00  
>>>  ERRORFRAME
>>>     lost-arbitration{at bit 2}
>>>  (000.000006)  can0  152   [8]  48 94 14 45 C3 60 8A 58
>>>  (000.000015)  can0  6D7   [4]  3A B8 84 26
>>>  (000.012537)  can0  20000002   [8]  02 00 00 00 00 00 00 00  
>>>  ERRORFRAME
>>>     lost-arbitration{at bit 2}
>> Why do you see these errors? Are there electrical problems on the CAN
>> bus? And if no cable is connected just txerr should increase (and
>> decrease if it's reconnected!
> These errors are occurring when I connect the cable again. They might be
> due to bad contact while plugging in the cable.

But you already receive *good* messages!

> Anyway. Like I said before, the controller does not enter error active
> state unless
> there is some other device sending on the bus. I've looked at "dmesg"
and
> there
> isn't even an interrupt. The netlink interface also says error-warning.

From http://www.kvaser.com/about-can/the-can-protocol/can-error-handling/

"The rules for increasing and decreasing the error counters are somewhat
complex, but the principle is simple: transmit errors give 8 error points,
and receive errors give 1 error point. Correctly transmitted and/or
received messages causes the counter(s) to decrease."
 
> When you were doing your experiments, did you perhaps have some node on
> the bus that might have answered to some of the cangen messages?
> 
> In any case, my setup is like this:
>  * Two sja1000 from the same peak_pci connected to the same bus.
>  * Both send using cangen
>  * Resistance: 60 Ohm

Hm, the cable should be terminated with 120 Ohm on both ends of the cable.
BTW: what bitrate do you use?

Wolfgang.