On Monday 07 February 2011, 16:33:30 Wolfgang Grandegger wrote: > >> 2. I forced the controller into bus-off by short-circuiting > >> > >> the low and high lines and sending a message (*), Then I > >> restarted the controller manually with > >> "ip link set can0 type can restart": > >> > >> On SJA1000: > >> > >> # ./candump -t d any,0:0,#FFFFFFFF > >> (*) > >> can0 20000004 [8] 00 08 00 00 00 00 88 00 ERROR-WARNING > >> can0 20000004 [8] 00 20 00 00 00 00 88 00 ERROR-PASSIVE > >> can0 20000044 [8] 00 00 00 00 00 00 7F 00 BUS-OFF > >> (**) > >> can0 20000100 [8] 00 00 00 00 00 00 00 00 RESTARTED > >> can0 20000004 [8] 00 40 00 00 00 00 00 00 ERROR-ACTIVE > >> > >> On SJA1000: > >> > >> # ./candump -t d any,0:0,#FFFFFFFF > >> (*) > >> can2 20000004 [8] 00 08 00 00 00 00 00 00 ERROR-WARNING > >> can2 20000040 [8] 00 00 00 00 00 00 00 00 BUS-OFF > >> (**) > >> can2 20000100 [8] 00 00 00 00 00 00 00 00 RESTARTED > >> can2 20000004 [8] 00 40 00 00 00 00 00 00 ERROR-ACTIVE > >> > >> The MSCAN seems not to signal the ERROR-PASSIVE state before > >> going bus-off. > >> > >> Would be interesting to see, how other CAN controllers behave. > >> > >> What do you think? Would that patch/approach fit your/our needs? > > > > Mh, it seems you have some other patches for candump.c/lib.c to actually > > print the state change. > > I added the strings like "ERROR_WARNING" at the end manually. I think > that's what you mean!? I once started to make a patch for candump to > print the meaning of the CAN id and data fields in a human readable > format. That would be a nice to have. I'm going to dig for it.
Ah, ic. Yes, this is what I want to know. > > 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? > > 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. Alexander _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
