On Mon, Feb 1, 2010 at 7:56 AM, Paul Thomas <[email protected]> wrote:
>
> I've been running for several hours with "one-shot-mode off", and I haven't
> seen this happen again. Is it possible the higher level of the stack is
> getting confused by the low-level one-shot option?
>
Yeah, I didn't think about it. :-( One shot means that the
transmission may fail (for example for a bus arbitration lost). It
looks like that in this case we don't get a TX done interrupt. The
problem is that it's not clear to me if we get a MERR interrupt
either:
"· If the message started to transmit but encoun-
tered an error condition, the TXBnCTRL.TXERR
and the CANINTF.MERRF bits will be set and an
interrupt will be generated on the INT pin if the
CANINTE.MERRE bit is set
· If the message is lost, arbitration at the
TXBnCTRL.MLOA bit will be set
Note: If One-shot mode is enabled
(CANCTRL.OSM), the above conditions
will still exist. However, the TXREQ bit will
be cleared and the message will not
attempt transmission a second time."
and from the flow chart "FIGURE 3-1: TRANSMIT MESSAGE FLOWCHART" I
would say no. So this explains why the netif queue is never woken up
even with the MERR handling (but can you confirm this?). The first
thing that comes to my mind is using the standard netdev tx watchdog
to restart it, but I don't know it's an elegant solution.
--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
