RE: Error recovery using MCP2515 can controller

Hi Chuck

> 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'd say the answer is it all depends on the type of electrical interference
your bus is experiencing.  Many years ago we had one system that only had
errors when a stepper motor driver became operational.  We weren't able to
reduce the noise from the drive so we ended up putting ferrite balun cores
with one loop on CAN_H and CAN_L before it went into the node.
http://www.amidoncorp.com/multi-aperture-cores/.  Spread over the entire
network it added considerable inductance and reduced the chopping drive
spikes to a level below the threshold of the CAN receiver.  No more high
speed TTL spikes into the 82C200 CAN chip.

Since you have a long bus, the capacitor at the end with split termination
may not have a large impact on noise at the center of the bus.

> 
> I was not able to find a web site for the WSC-10 CAN bridge you
referenced,
> can you supply a link?
http://www.tke.fi/networking/wcs-10

> 
> 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 :-)

Yes.  Fundamental rule.  No identical IDs unless you have a master slave
synchronous TDMA type system.
> 
> 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:

I've not experienced that with the MCP2510/2515 devices.  By CAN rules the
one time a node does _not_ go bus off and stop sending is when there is no
ACK.  So check your firmware.  I use that feature to determine if I've set
the bit rate correctly when playing with a new CAN device or processor.
Happened just last week in fact.  Discovered that the PIC18LF2620 running at
3.3V works quite well, most of the time, with a 10MHz crystal and 4xPLL mode
or an FOSC of 40MHz.  
Spent a day pouring through code. Cleaning things up. Worked 95% of the time
but occasionally would miss messages.  Two different CAN dongles and
software also received the messages.  As well ,my TEK scope also parsed the
messages.  One dongle didn't reliably.  Put the software into a different
board with a 5V PIC18F2680  (note no 'L' and 5V) and it worked perfectly
with everything.  Had to be hardware.

Finally as an act of desperation I went back into the data sheet.  Hmmm.
PIC18LF2680 Vcc needs to be  4.2V if I want to run 40MHz.  An FOSC of 25Mhz
is max at 3.3V.  The easiest part to replace on the board was the crystal
from 10Mhz down to 6MHz for a 24MHz FOSC.  Now rock solid.    

But I had to change from 20 Tq per bit to 12 Tq per bit.  Sampling at 83%.
Running on an open network with just one 120 Ohm resistor I scoped it and
after a few tries of incorrect math I saw the smallest bits showing up at
4uS wide.  So continuous transmission is useful.  

Setting your sample point at 85% (600m bus length) or even 87.5% (617m or
2014') if your Tq resolution allows it allows the greatest length of bus but
rounding on the waveforms might cause issues.  A SJW greater than 1 will
reduce the length too.  
> 
> "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):
It only goes bus off for errors other than missing ACK.

> 
> "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.

The devices still transmit when error passive.  They just no longer
contribute ERROR flags to damage a message they think is bad.  That prevents
a defective node from destroying all messages.  At some point it will go bus
off and then you have to decide what to do next.  Bus off is critically
serious.  Should never happen.  If it does you have to address the hardware
that is causing that.  For example, is your system easy enough to change so
you are sending 20kbps.  If you put a scope on it do you see noise in the
dominant bits?  Do you see noise in the recessive parts?

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

A bus off situation is pretty easy.  Clear out the transmit flags.  Then go
bus on.    Stale data gone.  What to do with error passive for transmit is
up to your application.  You might well want to cancel the data at that
point.
There are lots of ways to queue up the data messages in such a way that they
have a lifetime and are pulled when stale.  That same approach can also
insert higher priority messages ahead of lower one.  Or use the transmit
buffers to handle that.

I used the MCP2510/2515 for my CANRF.  I found after a while with no
transmissions that the automatic gain part of the RF section would move the
data slicer level down to the noise floor.  The MCP2510 always operated in
error passive mode.  It had to by virtue of the medium as the noise floor
then caused spikes that the MCP2510 saw as start bit edges.  

Normally ON OFF KEYING transmission sends a preamble bit stream of
alternating 1's and 0's to condition all the receivers to properly decode
their respective signals to decode lows and highs.  Then they send the
message.  I didn't have that option with the MCP2510 so I configured the
highest priority transmit object to have an ID with 0's and 1's and no data.


Any time I sent a message after a bus quiet time I'd enable both transmit
objects.  The high priority one and the one with the real message.  The high
priority is always sent first by the MCP2510 followed immediately by the
real message.  The first one might go twice since a receiving node might not
'get' it the first time.  But the second time it would be ACK'd and then the
MCP2510 would send the real message.  Once the network was busy the message
hopping would deliver the message to the correct node.

But ZigBee is better which is why I don't make a CANRF anymore.

John Dammeyer


> 
> 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]>

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