Hi, On 02/08/2011 08:33 AM, Alexander Stein wrote: > On Monday 07 February 2011, 21:32:49 Wolfgang Grandegger wrote: >> On 02/07/2011 05:09 PM, Alexander Stein wrote: >>> On Monday 07 February 2011, 16:33:30 Wolfgang Grandegger wrote: >> ... >> >>>>> Well, on the other hand, at91_can, flexcan and pch_can are the only >>>>> controllers currently sending an CAN_ERR_ACK in can_id. Which you will >>>>> be spammed with. >>>> >>>> Yes, that are the infamous "ack slot" errors. Strictly speaking the >>>> CAN_ERR_ACK is not correct. It sneaked in some time ago. It's a normal >>>> >>>> bus error and it should therefore be: >>>> cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR; >>>> >>>> cf->data[2] |= CAN_ERR_PROT_UNSPEC; >>>> >>>> cf->data[3] |= CAN_ERR_PROT_LOC_ACK; /* ACK slot */ >>>> >>>> That's what the SJA1000 reports and a few other drivers need to be fixed >>>> as well. >>>> >>>> See also >>>> http://www.mail-archive.com/[email protected]/msg00212.ht >>>> ml >>> >>> Mh, for what was CAN_ERR_ACK inserted then, if this is not the ack slot >>> error? >> >> git blame says: >> >> $ git blame -L 25,25 error.h >> 0d66548a (Oliver Hartkopp 2007-11-16 15:52:17 -0800 25) #define >> CAN_ERR_ACK >> >> Therefore it's in mainline since the beginning. I think it was intended > > Well, the commanet after CAN_ERR_ACK says "received no ACK on transmission" > which is what I would expect. On the other hand CAN_ERR_PROT_LOC_ACK and > CAN_ERR_PROT_LOC_ACK_DEL seem to indicate a more detailed information about > the same error. I think CAN_ERR_ACK should be set in every case (also easy to > filter then as it is in can_id) and CAN_ERR_PROT_LOC_ACK and/or > CAN_ERR_PROT_LOC_ACK_DEL should be set if available/possible.
Well, strictly speaking the error belongs to the class of bus errors. Even if I don't see a need for that extra class, we need it for backward compatibility and therefore all drivers should set CAN_ERR_ACK for ack slot errors. >> for CAN controllers using a simple error reporting like the i82527. > The >> AT91 manual states: >> >> "Acknowledgment error (AERR bit in the CAN_SR register): The transmitter >> checks the Acknowledge Slot, which is transmitted by the transmitting node >> as a recessive bit, contains a dominant bit. If this is the case, at least >> one other node has received the frame correctly. If not, an Acknowledge >> Error has occurred and the transmitter will start in the next bit-time an >> Error Frame transmission." >> >> I have no problem to set CAN_ERR_ACK if it's really useful. But then it >> should be done for all drivers. > > Yes, of course, see above. > >>>>> But using an own application to send/receive some CAN messages where I >>>>> parse the error frames (ignoring ACK error though), I currently use >>>>> CAN_ERR_PROT_ACTIVE to know when I got back active. >>>> >>>> That was implemented by Mark but we need a general solution for all >>>> drivers. >>> >>> Mh, it would be good to know which flags are used for what. It seems the >>> docs and examples are a bit quiet about error handling/messaging. >> >> Well, we have: >> >> http://lxr.linux.no/#linux+v2.6.37/Documentation/networking/can.txt#L434 >> http://lxr.linux.no/#linux/include/linux/can/error.h >> >> Could be improved, of course. Also be aware, that error reporting is >> heavily hardware dependent. The SJA100 has a very comprehensive error >> reporting while the MCP251x reports almost nothing. > > Well, I expected that at least the most common errors are reported similar > from different CAN controllers, as far as possible. That's the goal, of course. Patches are welcome. Wolfgang, _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
