2011/1/14 Wolfgang Grandegger <[email protected]> > On 01/14/2011 05:56 PM, Willy Lambert wrote: > >> > >> So it seems to communicating :) > > Congrats! >
As I received an heavy support from here, here is a quick summary of what made things working (maybe it'll help someon a day) : - The board is an Ixxat PC-I 04/104 an a top of a PC104 CPU into wich I put a linux Debian with a personnal 2.6.35.7 kernel. - Physical configuration to use "Shared High interrupts" : I needed to solder the JP14 jumper to close it (just some tin, no resistor). JP20 has to be left open (one is enougth and no more than one cloased is allowed). The other jumpers where JP12 and JP13 on 3-4, JP15 and JP21 to defaults (2-3) - BIOS configuration : I needed to activate in the PCI/Pnp tab : _ Reserved Memory = 64K _ Memory Adress = 0hD0000 _ mettre les IRQ 5 et 7 en “Reserved” > > > During a "stress test" I have 2 controller error messages : > > > > 39 <http://lxr.linux.no/linux+*/include/linux/can/error.h#L39>#define > > CAN_ERR_CRTL_TX_WARNING > > <http://lxr.linux.no/linux+*/+code=CAN_ERR_CRTL_TX_WARNING> 0x08 /* > > reached warning level for TX errors */ > > <http://lxr.linux.no/linux+*/include/linux/can/error.h#L40> > > <http://lxr.linux.no/linux+*/+code=CAN_ERR_CRTL_RX_PASSIVE> > > 41 <http://lxr.linux.no/linux+*/include/linux/can/error.h#L41>#define > > CAN_ERR_CRTL_TX_PASSIVE > > <http://lxr.linux.no/linux+*/+code=CAN_ERR_CRTL_TX_PASSIVE> 0x20 /* > > reached error passive status TX */ > > ... > > > candump view : > > > > can0 0 [2] 81 00 > >> can0 721 [1] 00 > >> can0 0 [2] 01 00 > >> can0 1A1 [2] 60 00 > >> can0 721 [0] remote request > >> can0 321 [5] FD FF FF FF FF > >> can0 721 [1] 05 > >> can0 321 [5] 0F 00 00 00 00 > >> can0 721 [0] remote request > >> can0 1A1 [2] 27 00 > >> can0 721 [1] 85 > >> can0 321 [5] 93 FF 04 00 00 > >> can0 321 [5] 93 00 00 00 00 > >> can0 321 [5] 93 00 01 00 00 > >> can0 321 [5] 93 00 02 00 00 > >> can0 321 [5] 93 00 03 00 00 > >> can0 321 [5] 93 00 04 00 00 > >> can0 321 [5] 93 00 05 00 00 > >> can0 321 [5] 93 00 06 00 00 > >> can0 321 [5] 93 00 07 00 00 > >> can0 321 [5] 93 00 08 00 00 > >> can0 321 [5] 93 00 09 00 00 > >> can0 321 [5] 93 00 10 00 00 > >> can0 321 [5] 93 00 11 00 00 > >> can0 321 [5] 93 00 12 00 00 > >> can0 321 [5] 93 00 13 00 00 > >> can0 321 [5] 93 00 14 00 00 > >> can0 321 [5] 93 00 15 00 00 > >> can0 321 [5] 93 00 16 00 00 > >> can0 321 [5] 93 00 17 00 00 > >> can0 321 [5] 93 00 18 00 00 > >> can0 321 [5] 93 00 19 00 00 > >> can0 321 [5] 93 00 20 00 00 > >> can0 321 [5] 93 00 19 00 00 > >> can0 321 [5] 93 00 18 00 00 > >> can0 321 [5] 93 00 17 00 00 > >> can0 321 [5] 93 00 16 00 00 > >> can0 321 [5] 93 00 15 00 00 > >> can0 321 [5] 93 00 14 00 00 > >> can0 321 [5] 93 00 13 00 00 > >> can0 321 [5] 93 00 12 00 00 > >> can0 321 [5] 93 00 11 00 00 > >> can0 321 [5] 93 00 10 00 00 > >> can0 321 [5] 93 00 09 00 00 > >> can0 321 [5] 93 00 08 00 00 > >> can0 20000004 [8] 00 08 00 00 00 00 67 0C ERRORFRAME > >> can0 20000004 [8] 00 20 00 00 00 00 87 0C ERRORFRAME > >> can0 721 [1] 00 > >> can0 321 [5] 93 00 07 00 00 > >> can0 321 [5] 93 00 06 00 00 > >> can0 321 [5] 93 00 05 00 00 > >> can0 321 [5] 93 00 04 00 00 > >> can0 321 [5] 93 00 03 00 00 > >> can0 321 [5] 93 00 02 00 00 > >> can0 321 [5] 93 00 01 00 00 > >> can0 321 [5] 93 00 00 00 00 > >> > > > > > > > > May this be due to wiring quality ? > > Yes, or some mismatching bittiming. The bus errors are reported by the > SAJ1000 chip and you can get more details information, if you use the > "ip" argument "berr-reporting on". Also "ip -d -s link show can0" > reports the number of bus-errors. > > Wolfgang. >
_______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
