RE: "Lost Arbitration"

Chuck,
The lost arbitration is for information only.   Very useful in some high
level protocols.

 It's hard to comment on how your messaging works without knowing more about
your high level protocol.  How you've assigned IDs.  How you decide when and
how often to send messages.  It's possible to create an HLP that provides
timely information and yet doesn't overflow receive buffers or have large
amounts of arbitration.  

Arbitration isn't bad.  It means that the system is working correctly.
Since higher priority IDs always win, however, it's possible to design an
HLP that prevents lower priority nodes from ever succeeding.  So they'd
arbitrate forever.  

Perhaps describe how you've designed the protocol.

John

> -----Original Message-----
> From: [email protected] [mailto:canlist-
> [email protected]] On Behalf Of Chuck Hackett
> Sent: September-21-14 3:52 PM
> To: [email protected]
> Subject: [CANLIST] "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]>

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