Re: GS_USB

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 11.11.2013 20:49, Max S. wrote:
> Hmm. Seems I missed something.
> 


>>>
>>> http://lxr.free-electrons.com/source/Documentation/networking/can.txt#L891
>>>
>>>
>>
>> Yes.
>>
>> Usually the CAN controller sits in BUS_OFF until it detects correct CAN frames
>> _or_ until the controller is re-initialized.
> 
> From the CAN2.0A spec chapter 7
> 12. An node which is ’bus off’ is permitted to become ’error active’ (no
> longer ’bus off’) with its error counters both set to 0 after 128
> occurrence of 11 consecutive ’recessive’ bits have been monitored on the
> bus.

Hm - I assume this does not mean 128*11 bits but 128 occurences of 11
consecutive ’recessive’ bits with at least one dominant bit in between.
But I'm not sure about that.

> 
> So: When the controller goes into bus off because of a short on can high
> to low. It will inevitably observe recessive bits. and consequently come
> back out of bus off. It will then attempt to resend and hit bus off
> again. rinse & repeat.


> 
> Why is it necessary to be able to get the controller out of bus off
> manually?

Think about a misconfigured bitrate.
The application should decide if it's better to stay calm (in BUS_OFF) or
whether it should try to re-initialize the CAN controller and start again.

> 
> I was able to improve the firmware to make status updates faster.
> The following is the current state: @250K bitrate
>  (000.000011)  can0  20000040   [8]  00 00 00 00 00 00 00 01  ERRORFRAME
> 	bus-off
> 	error-counter-tx-rx{{0}{1}}
>  (000.005980)  can0  20000100   [8]  00 00 00 00 00 00 00 80  ERRORFRAME
> 	restarted-after-bus-off
> 	error-counter-tx-rx{{0}{128}}
>  (000.000013)  can0  20000008   [8]  00 00 40 00 00 00 00 00  ERRORFRAME
> 	protocol-violation{{back-to-error-active}{}}
>  (000.000006)  can0  20000004   [8]  00 08 00 00 00 00 60 00  ERRORFRAME
> 	controller-problem{tx-error-warning}
> 	error-counter-tx-rx{{96}{0}}
>  (000.000008)  can0  20000004   [8]  00 20 00 00 00 00 80 00  ERRORFRAME
> 	controller-problem{tx-error-passive}
> 	error-counter-tx-rx{{128}{0}}
>  (000.002014)  can0  20000040   [8]  00 00 00 00 00 00 00 01  ERRORFRAME
> 	bus-off
> 	error-counter-tx-rx{{0}{1}}
> 
>>
>> The CAN controller should not recover itself as this might be wrong depending
>> on the use-case.
> 
> Is recovery (getting out of bus off) not part of the CAN spec?

As discussed above the controller get's out of the BUS_OFF state when
receiving correct CAN traffic.

Or by kicking the controller by restarting it :-)

> 
>>
>> Therefore the manual "restart" can be initiated by some user application or it
>> can be handled inside the driver e.g. 200ms after a BUS_OFF detection by the
>> "restart-ms" option.
>>

Regards,
Oliver