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