RE: Error recovery using MCP2515 can controller

Hi John,

Thanks much for the info.  I may have more questions as I digest it.  I am
currently using a non-split terminator but am looking to split it.  I have
seen two cases: 1) two 60 ohm resistors to GND, and, 2) two 60 ohm resistors
connected to a cap which is connected to GND.  

Which do you suggest?  If w/cap, what value cap? (keep in mind that my bus
is at 125kbps or lower).

I was not able to find a web site for the WSC-10 CAN bridge you referenced,
can you supply a link?

Even though you observe that "Ideally you should never see the standard
errors" my world is far from ideal :-)

I discovered one error I ran into in a contrived setup just to test bus
throughput and interrupt rates - I had inadvertently set it up so that the
two nodes were sending the same (extended) CANID but different message
contents.  Took me awhile to figure out that both thought they were
'winning' arbitration and their data was colliding = my bad :-)

At the moment I am trying to add better error recovery to my (ATMega1284p)
driver for the MCP2515 CAN controller.

The two main situations I am currently addressing:
- total failure (I.e.: controller can not send successfully)
- errors caused by bus being too long (arbitration fails due to late signals
from far end of cable) and severed cable (i.e.: lost termination(s)).

I need to understand better where the MCP2515 error recovery ends and the
firmware's error recovery needs to start.

My current testing involves the controller driving (via MCP2551 driver) a
zero length bus (just a 60 ohm resistor).  This obviously sets up a
situation where the controller never receives an acknowledgement.

In my testing it appears that the MCP2515 stops sending ... or, at least
stops generating message completions (or any interrupts other than receive
message completions) ... when in the "error-passive" state even though the
datasheet (section 6.6) says:

"In the error-passive state, messages and passive error frames (made of
recessive bits) may be transmitted."

My understanding was that message transmission continues until the
controller is in the "Bus-Off" state (again from datasheet):

"The bus-off state makes it temporarily impossible for the station to
participate in the bus communication.  During this state, messages can
neither be received or transmitted. Only transmitters can go bus-off."

Can anyone shed light on this?

For the purposes of my driver, my assumption is that, when the controller
enters a non-transmitting state (seemingly Error-Passive from my current
observations) I need to abort any current xmit buffers and flush all
messages in the MCU xmit queue (they are processed further internally),
disable transmitting and re-enable transmission after a suitable delay via a
timer interrupt.

BTW: I can't let the MCU xmit queue build while not transmitting because the
data gets 'stale'.
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

> -----Original Message-----
> 
> Hi Chuck,
> 
> Ideally you should never see the standard errors.  When the bus 
> reaches the point of Error Warning there is something wrong and you 
> are best to address the bus issues that cause the errors.
> .... 
> So bus loading is heavily
> dependent on your High Level Protocol.
> 
> In either case do handle the interrupts that occur from the various 
> bus errors and let your application parameters decide whether they 
> node should shut down or go back bus on with a warning to the central
system.
> 
> Best Regards
> John Dammeyer


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>