Hello,

SETTE AGOSTINO - technolabs wrote:
> Hi All,
>  
> I have a card with a Bosch CC770 CAN Controller but I have some
> problems:
>  
> 1. I Applied the patch suggested by BOSCH, Ref. CC770 (Stand Alone CAN
> Controller) Data Sheet Revision 1.6 30.03.2009

Interesting, could you give me the link to that patch?

> 
>    9.1 Description
> 
>    In chapter chapter 4.2 the description of the EIE bit suggests, that
> a change in the error status
>    will cause an interrupt to be generated. That means, if bits BOff or
> Warn in Status register
>    (01H) are changing from 0 to 1 or vice versa from 1 to 0 an interrupt
> will be generated. In
>    such a case, usually an interrupt routine reads the Interrupt
> register (5FH) to determine the
>    interrupt source and then reads the Status register (01H) to
> acknowledge the interrupt and
>    this deactivates the interrupt line.
>    The behaviour of the error status Warn is as described, but the
> behaviour of the error status
>    BOff is not as described. The error status BOff does not trigger the
> Interrupt register by a
>    change (edge triggered), but by level. Thus, in Bus Off state, the
> Interrupt register is forced
>    to 01H and hence the interrupt line remains active. The only way to
> deactivate the interrupt
>    line is to reset the IE bit in the Control register, a read to the
> Status register has no effect.
> 
>    9.2 Work-around
> 
>    On occurrence of a Bus Off interrupt, the CPU shall reset the IE bit
> in the Control register to
>    deactivate the interrupt line. To re-synchronize the CC770 to the CAN
> bus, the Bus Off
>    Recovery Sequence shall be started by resetting the Init bit in the
> Control register. After
>    successful resynchronisation, the BOff flag in the Control register
> will be reset by CC770.
>    The software shall poll for this state and, if reached, it may
> re-enable the CC770 interrupt by
>    setting IE bit in the Control register.
>    Please note that leaving BusOff state (resetting BOff and Warn bits)
> will also cause an Error
>    interrupt. In this case, reading the Status register clears the
> Interrupt register.
> 
>    And it works properly. Unfortunately now I have some "Stuff Error"
> and "Form Error".
>    The causes of these errors, AFAIK, are:
> 
>    Stuff Error
>    1. a disturbance generates more consecutive bits of equal level than
> allowed by the rule of 
>       bit stuffing and therefore the error is detected by all nodes.
>    2. a disturbance falsifies one or more of the five bits preceeding
> the stuff bit. This error 
>       is not recognized by a receiver; however, if the error also
> appears at the transmitter, 
>       it will be detected as a bit error (transmitter monitors bus as it
> transmits).
> 
>    In any case, the error is detected by a receiver either by the bit
> stuffing mechanism (the 
>    stuff bit of the transmitter is not dropped but taken as an
> information bit) or by the CRC check.
> 
>    Form Error
>    Form Errors result from the violation of the fixed form of the
> following bit fields:
>    - end of frame
>    - interframe space
>    - ACK delimiter
>    - CRC delimiter
>    During the transmission of these bit fields, an error condition is
> recognized if a "dominant" bit 
>    level is detected.
> 
>    My question is: are these errors detected on the TX side or on the RX
> side? It seems to be in TX, as far 
>    as I can understand but I would like to have a confirmation.

I will first answer the following questions.

> 2. Where can I find the Linux drivers for the Bosch CC770?

There is a Socket-CAN driver for the CC770 or AN82527 in the SVN
repository at BerliOS:

http://developer.berlios.de/projects/socketcan/
http://svn.berlios.de/svnroot/repos/socketcan/trunk/kernel/2.6/drivers/net/can/cc770/

How is the chip connected to your system (what bus)?

> 3. I would like to know how the Bus_off problem in the interrupt handler
> is managed in the kernel tree.

I will have a close look to what you are speaking about later on.

Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to