"Lost Arbitration"

This weekend I installed the new driver code in nine nodes.

The bus performed better, I think mostly due to changing the timing
parameters and improved error recovery in the firmware-to-MCP2515 interface.

As part of the upgraded driver I am gathering a lot more statistics from the
interface.

I am getting a large number of “Lost Arbitrations” as reported by the
MCP2515.  This counter is incremented when an interrupt occurs with a TXnIF
bit set in the CANINTF register indicating xmit complete and with the
"TXREQ" bit is clear and the "MLOA" bit set in the TXBnCTRL register.

It is my understanding that "Lost Arbitrations" are a normal consequence of
the CAN bus access scheme and would be retried by the controller until the
message won arbitration and was successfully sent (I am not using "One-Shot"
mode).

From reading the datasheet it is unclear to me if these “Lost Arbitration”
transmit 'completions' are:

- “failures”: The message was not sent successfully and the MCP2515 has
retried the message as much as reasonable, or

- “retryable”: The message was not sent successfully and the driver should
re-attempt the send if it desires, or

- "information":  The message was sent successfully and the MLOA is just
indicating that the message lost arbitration one or more times before being
successfully sent

From looking at the "Transmit Message Flowchart" in the datasheet it seems
that the only place the TXRQ bit is cleared is after the message has been
successfully transmitted.  This also seems to be the only place the TXnIF
bit is set.

This would seem to indicate that (unless the message is aborted by the user
by clearing the TXRQ bit) the controller keeps trying to send any message
forever - and, the interrupt with the TXnIF bit set indicates that the
message was SUCCESSFULLY transmitted - and, the TXERR and MLOA bits only
indicate that an error/lost arbitration occurred prior to the message being
sent successfully ... Correct?

If this is true, I can consider "TXERR" (xmit error) and "MLOA" (lost
arbitration) bits as 'informative' and not a cause for concern unless
traffic is not flowing (indicating noise, congestion, etc.)

I am also getting some "receive buffer overruns" which I am looking into.  I
think these are due to the level of interrupts I have currently (ADC, UART,
TWI, MCP2515, etc.).  

In the MCP2515 I have rollover from rcv buf 0 to buffer 1 turned on and
"accept all valid messages with extended ID meeting filters" mode set for
both buffers with all filters set to all zero (accept all).  Messages are
filtered in background by the firmware as there is nothing in the ID I can
filter on in this application.  I am currently running at an average of 22
messages per second (unknown peek due to 'bunching').  I assume that the
buffer overruns are occurring during the "bunching".
 
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


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