At the moment I have :

r...@alpha:/opt/ard# ip -d -s link show can0
> 17: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> qlen 10
>     link/can
>     can state ERROR-ACTIVE restart-ms 10000
>     bitrate 500000 sample-point 0.875
>     tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>     sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>     clock 8000000
>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>     0          0          0          0          0          0
>     RX: bytes  packets  errors  dropped overrun mcast
>     0          0        0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     0          0        0       0       0       0
>



candump does not show anything !


 # candump any,0:0,#FFFFFFFF
>



2010/11/14 Willy Lambert <[email protected]>

> thanks for answers, I will correct electrical doubts (resistor and 2nd
> device) before going ahead.
>
> A virtual device could manage baudrate. It depends how far the simulation
> goes, that's why I were asking.
>
> cabling can0 into can1
>>
> I have 2 can controllers on my board so I was thinking about connecting the
> port of the first into the port of the second in order to have a 2nd device
> on can.
>
> I didn't see anywhere a definition of my can ID or masteR/slave type. Is it
> a pure soft definition or shall I define something in my linux interface
> configuration ?
>
> 2010/11/14 Wolfgang Grandegger <[email protected]>
>
> On 11/14/2010 04:26 PM, Willy Lambert wrote:
>> > Hi all,
>> >
>> > *The short story is :*
>> >
>> > I manage to use vcan0 but the same tests fails on my real can interface.
>> I
>> > am not sure about my HW livelyness but I really don't know where to look
>> at
>> > to see if everything is working.
>> >
>> > *The long one :*
>> >
>> > As I just found my way in the kernel modules, I'm am trying to send a
>> > message on my can bus. to begin smoothly, I loaded a vcan modules and
>> tried
>> > cansend et candump with this script :
>> >
>> >>         echo "Inserting can drivers..."
>> >>         echo "insert can"
>> >>         modprobe can
>> >>         echo "insert can_raw"
>> >>         modprobe can_raw
>> >>         echo "insert can_bcm"
>> >>         modprobe can_bcm
>> >>         echo "insert vcan"
>> >>         modprobe vcan
>> >>
>> >>         echo "Configuring can ..."
>> >>         ip link add dev vcan0 type vcan
>> >>         ip link add dev vcan1 type vcan
>> >>         ip link set up vcan0
>> >>         ip link set up vcan1
>> >>
>> > And creates this can.log file :
>> >
>> >> (0.1) vcan0 5D1#0000
>> >> (0.2) vcan0 271#0100
>> >> (0.3) vcan0 289#72027000
>> >> (0.4) vcan0 401#081100000000
>> >>
>> >
>> > in one term I send :
>> >
>> >> ?>canplayer -l i -L can.log
>> >> in an other one I receive :
>> >> ?>candump vcan0
>> >>
>> >
>> > (by the way if someone could tell me how to configure vcan speed, if it
>> is
>> > meaningfull)
>>
>> It's *not* meaningfull. It's a *virtual* device.
>>
>> > Then I tried the same thing with my real hardware using this script :
>> >
>> >>         echo "Inserting can drivers ..."
>> >>         modprobe can
>> >>         echo "insert can_raw"
>> >>         modprobe can_raw
>> >>         echo "insert can_bcm"
>> >>         modprobe can_bcm
>> >>         echo "insert sja1000"
>> >>         modprobe sja1000
>> >>         echo "insert sja1000_isa"
>> >>         insmod $MODPATH/drivers/net/can/sja1000/sja1000_isa.ko irq=5,7
>> >> mem=0xD0000,0xD0200
>> >>
>> >>         echo "Configuring can drivers ..."
>> >>         ip link set can0 type can bitrate 500000
>> >>         ip link set can1 type can bitrate 500000
>> >>         ip link set can0 type can restart-ms 10000
>> >>         ip link set can1 type can restart-ms 10000
>> >>         ifconfig can0 up
>> >>         ifconfig can1 up
>>
>> BTW: you could set everything with one command:
>>
>>        ip link set can0 up type can bitrate 500000 restart-ms 10000
>>
>> > and uses the same commands after having changed "vcan0" into "can0" in
>> my
>> > can.log file.
>> > As a result I have a full buffer error message (killing cansend) :
>> >
>> >> r...@alpha:/opt/ard# ../canplayer -l i -I can.log
>> >> sendto: No buffer space available
>>
>> It seems that no can messages are going out to the bus, likely due to
>> electrical problems.
>>
>> > Here, I am totally lost, I don't know what to look at, I don't event
>> know if
>> > my can hw is running. Could someone ligth up my path ?
>> > I tried different configuration like :
>> > _ no cabling
>>
>> Well, no comment.
>>
>> > _ cabling can0 into can1
>>
>> You mean connecting can0 and can1 to the same CAN bus/cable!?
>>
>> > _ cabling on open can0
>>
>> I don't understand!?
>>
>> > I am not sure about my 120 Ohm resistors, I will check this on Monday,
>> but
>> > as I am just trying to send is the real bus needed ?
>>
>> Yes, you need a bus with a least one node responding to CAN messages.
>> Otherwise the bus error count of the device will increase and even reach
>> the bus-off state. The cable *must* be terminated with 120 Ohm at *each*
>> end of CAN bus cable.
>>
>> > Here is some information I find relevant for analysis, I don't know what
>> you
>> > need to look into my problem.
>>
>> There a few tools and commands useful for debugging:
>>
>> - List the CAN setting and statistics after sending a message:
>>
>>  # ip -d -s link show can0
>>  # ip -d -s link show can1
>>
>> - Dump real and error CAN messages while you send a message:
>>
>>  # candump any,0:0,#FFFFFFFF
>>
>> Could you please show us the output of the above two commands.
>>
>> Wolfgang.
>>
>
>
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users

Reply via email to