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.html > > 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 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. >>> 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. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
