can acknowledgment

can acknowledgment

[Michael Muldoon]

So I have a decent amount of experience with can but this is my first
time using it on a linux device and therefore my first experience with
socket-can.  Anyway the problem is that I am unable to view any can
messages on the network without two other can devices on it currently
a pcan from preak systems and an intrepid fire.  Also I'm unable to
send can messages.  Everything seems to be pointing to a can
acknowledgment issue which I have had experience with before but I
can't seems to figure out the root cause of it here.

RE: can acknowledgment

[Aiken, Scott]

Did you set the right bit rate for your network?
Do you have a bus analyzer to see if your target is trying to transmit?

This may tell you why your target isn't happy:
    int errFilter = CAN_ERR_TX_TIMEOUT |
             CAN_ERR_LOSTARB | CAN_ERR_CRTL |
             CAN_ERR_PROT | CAN_ERR_TRX | CAN_ERR_ACK |
             CAN_ERR_BUSOFF | CAN_ERR_BUSERROR |
             CAN_ERR_RESTARTED; /* see linux/can/error.h */
    setsockopt( s, SOL_CAN_RAW, &errFilter, sizeof(errFilter) );

And watch for error messages...


-----Original Message-----
From: linux-can-owner@vger.kernel.org [mailto:linux-can-owner@vger.kernel.org] On Behalf Of Michael Muldoon
Sent: Wednesday, September 04, 2013 12:48 PM
To: linux-can@vger.kernel.org
Subject: can acknowledgment

So I have a decent amount of experience with can but this is my first time using it on a linux device and therefore my first experience with socket-can.  Anyway the problem is that I am unable to view any can messages on the network without two other can devices on it currently a pcan from preak systems and an intrepid fire.  Also I'm unable to send can messages.  Everything seems to be pointing to a can acknowledgment issue which I have had experience with before but I can't seems to figure out the root cause of it here.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: can acknowledgment

[Michael Muldoon]

Thanks for responding.  The bitrate is definitely right if I send the
candump command I can see the traffic being sent by the other two
devices on the network. The problem is if I take either of the other
two devices off the network candump sees nothing and at not point does
cansend ever work.

On Wed, Sep 4, 2013 at 4:19 PM, Aiken, Scott <Scott.Aiken@karlstorz.com> wrote:
> Did you set the right bit rate for your network?
> Do you have a bus analyzer to see if your target is trying to transmit?
>
> This may tell you why your target isn't happy:
>     int errFilter = CAN_ERR_TX_TIMEOUT |
>              CAN_ERR_LOSTARB | CAN_ERR_CRTL |
>              CAN_ERR_PROT | CAN_ERR_TRX | CAN_ERR_ACK |
>              CAN_ERR_BUSOFF | CAN_ERR_BUSERROR |
>              CAN_ERR_RESTARTED; /* see linux/can/error.h */
>     setsockopt( s, SOL_CAN_RAW, &errFilter, sizeof(errFilter) );
>
> And watch for error messages...
>
>
> -----Original Message-----
> From: linux-can-owner@vger.kernel.org [mailto:linux-can-owner@vger.kernel.org] On Behalf Of Michael Muldoon
> Sent: Wednesday, September 04, 2013 12:48 PM
> To: linux-can@vger.kernel.org
> Subject: can acknowledgment
>
> So I have a decent amount of experience with can but this is my first time using it on a linux device and therefore my first experience with socket-can.  Anyway the problem is that I am unable to view any can messages on the network without two other can devices on it currently a pcan from preak systems and an intrepid fire.  Also I'm unable to send can messages.  Everything seems to be pointing to a can acknowledgment issue which I have had experience with before but I can't seems to figure out the root cause of it here.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: can acknowledgment

[Aiken, Scott]

Hmm, you can't ack or send.  Is your CAN_TX pin correctly wired to the port?

-----Original Message-----
From: Michael Muldoon [mailto:mbmuldoon07@gmail.com] 
Sent: Wednesday, September 04, 2013 1:41 PM
To: Aiken, Scott
Cc: linux-can@vger.kernel.org
Subject: Re: can acknowledgment

Thanks for responding.  The bitrate is definitely right if I send the candump command I can see the traffic being sent by the other two devices on the network. The problem is if I take either of the other two devices off the network candump sees nothing and at not point does cansend ever work.

On Wed, Sep 4, 2013 at 4:19 PM, Aiken, Scott <Scott.Aiken@karlstorz.com> wrote:
> Did you set the right bit rate for your network?
> Do you have a bus analyzer to see if your target is trying to transmit?
>
> This may tell you why your target isn't happy:
>     int errFilter = CAN_ERR_TX_TIMEOUT |
>              CAN_ERR_LOSTARB | CAN_ERR_CRTL |
>              CAN_ERR_PROT | CAN_ERR_TRX | CAN_ERR_ACK |
>              CAN_ERR_BUSOFF | CAN_ERR_BUSERROR |
>              CAN_ERR_RESTARTED; /* see linux/can/error.h */
>     setsockopt( s, SOL_CAN_RAW, &errFilter, sizeof(errFilter) );
>
> And watch for error messages...
>
>
> -----Original Message-----
> From: linux-can-owner@vger.kernel.org 
> [mailto:linux-can-owner@vger.kernel.org] On Behalf Of Michael Muldoon
> Sent: Wednesday, September 04, 2013 12:48 PM
> To: linux-can@vger.kernel.org
> Subject: can acknowledgment
>
> So I have a decent amount of experience with can but this is my first time using it on a linux device and therefore my first experience with socket-can.  Anyway the problem is that I am unable to view any can messages on the network without two other can devices on it currently a pcan from preak systems and an intrepid fire.  Also I'm unable to send can messages.  Everything seems to be pointing to a can acknowledgment issue which I have had experience with before but I can't seems to figure out the root cause of it here.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" 
> in the body of a message to majordomo@vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html

RE: can acknowledgment

[Aiken, Scott]

To ack, the device has to pull the CAN_TX pin low.  If the device's CAN_TX isn't actually connected to the bus for whatever reason (short, break, etc.), then it can't send or ack.  All it can do is listen to packets that are ack'ed by other nodes.

-----Original Message-----
From: Michael Muldoon [mailto:mbmuldoon07@gmail.com] 
Sent: Wednesday, September 04, 2013 2:05 PM
To: Aiken, Scott
Cc: linux-can@vger.kernel.org
Subject: RE: can acknowledgment

What do you mean by the CAN_TX pin? The can hi and lo are fine if either were messed up nothing would work. 
On Sep 4, 2013 4:52 PM, "Aiken, Scott" <Scott.Aiken@karlstorz.com> wrote:
Hmm, you can't ack or send.  Is your CAN_TX pin correctly wired to the port?

-----Original Message-----
From: Michael Muldoon [mailto:mbmuldoon07@gmail.com]
Sent: Wednesday, September 04, 2013 1:41 PM
To: Aiken, Scott
Cc: linux-can@vger.kernel.org
Subject: Re: can acknowledgment

Thanks for responding.  The bitrate is definitely right if I send the candump command I can see the traffic being sent by the other two devices on the network. The problem is if I take either of the other two devices off the network candump sees nothing and at not point does cansend ever work.

On Wed, Sep 4, 2013 at 4:19 PM, Aiken, Scott <Scott.Aiken@karlstorz.com> wrote:
> Did you set the right bit rate for your network?
> Do you have a bus analyzer to see if your target is trying to transmit?
>
> This may tell you why your target isn't happy:
>     int errFilter = CAN_ERR_TX_TIMEOUT |
>              CAN_ERR_LOSTARB | CAN_ERR_CRTL |
>              CAN_ERR_PROT | CAN_ERR_TRX | CAN_ERR_ACK |
>              CAN_ERR_BUSOFF | CAN_ERR_BUSERROR |
>              CAN_ERR_RESTARTED; /* see linux/can/error.h */
>     setsockopt( s, SOL_CAN_RAW, &errFilter, sizeof(errFilter) );
>
> And watch for error messages...
>
>
> -----Original Message-----
> From: linux-can-owner@vger.kernel.org
> [mailto:linux-can-owner@vger.kernel.org] On Behalf Of Michael Muldoon
> Sent: Wednesday, September 04, 2013 12:48 PM
> To: linux-can@vger.kernel.org
> Subject: can acknowledgment
>
> So I have a decent amount of experience with can but this is my first time using it on a linux device and therefore my first experience with socket-can.  Anyway the problem is that I am unable to view any can messages on the network without two other can devices on it currently a pcan from preak systems and an intrepid fire.  Also I'm unable to send can messages.  Everything seems to be pointing to a can acknowledgment issue which I have had experience with before but I can't seems to figure out the root cause of it here.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

Re: can acknowledgment

[Wolfgang Grandegger]

On Wed, 4 Sep 2013 16:40:37 -0400, Michael Muldoon <mbmuldoon07@gmail.com>

wrote:

> Thanks for responding.  The bitrate is definitely right if I send the

> candump command I can see the traffic being sent by the other two

> devices on the network. The problem is if I take either of the other

> two devices off the network candump sees nothing and at not point does

> cansend ever work.



What does "ip -d -s link show can0" list after you try sending out

messages?

And what does "candump -e any,0:0,#FFFFFFFF" report while sending?



Wolfgang.

Re: can acknowledgment

[Michael Muldoon]

Before doing anything
can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT qlen 10
    link/can
    can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 0
    bitrate 500000 sample-point 0.850
    tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1
    mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
    clock 10000000

candump works fine as long as there are two other devices on the
network if just one there is nothing.

after attempting to send a can message:
can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN
mode DEFAULT qlen 10
    link/can
    can <TRIPLE-SAMPLING> state BUS-OFF restart-ms 0
    bitrate 500000 sample-point 0.850
    tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1
    mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
    clock 10000000
    re-started bus-errors arbit-lost error-warn error-pass bus-off
    0          0          0          1          1          1
    RX: bytes  packets  errors  dropped overrun mcast
    101600     12700    0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       0       0       0
if restart-ms is set it doesn't go down after sending a can message.

Also the device I' using is a Janus-RC intelligent terminus using busy
box if you guys know anything about it and has two can networks and it
is exactly the same for both so I don't know if that means it could
still be a CAN_TX pin problem or not.

Thanks

On Thu, Sep 5, 2013 at 4:31 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On Wed, 4 Sep 2013 16:40:37 -0400, Michael Muldoon <mbmuldoon07@gmail.com>
> wrote:
>> Thanks for responding.  The bitrate is definitely right if I send the
>> candump command I can see the traffic being sent by the other two
>> devices on the network. The problem is if I take either of the other
>> two devices off the network candump sees nothing and at not point does
>> cansend ever work.
>
> What does "ip -d -s link show can0" list after you try sending out
> messages?
> And what does "candump -e any,0:0,#FFFFFFFF" report while sending?
>
> Wolfgang.
>

Re: can acknowledgment

[Wolfgang Grandegger]

On Thu, 5 Sep 2013 08:47:44 -0400, Michael Muldoon <mbmuldoon07@gmail.com>

wrote:

> Before doing anything

> can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN

> mode DEFAULT qlen 10

>     link/can

>     can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 0

>     bitrate 500000 sample-point 0.850

>     tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1

>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1

>     clock 10000000

> 

> candump works fine as long as there are two other devices on the

> network if just one there is nothing.



Is the remaining "one" in listen-only mode?



> after attempting to send a can message:

> can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN

> mode DEFAULT qlen 10

>     link/can

>     can <TRIPLE-SAMPLING> state BUS-OFF restart-ms 0



Well, you entered BUS_OFF!!! You need first recover using:



  # ip link set can0 type can restart



See

http://lxr.linux.no/#linux+v3.11/Documentation/networking/can.txt#L882.



This means that there are electical problems on the CAN bus. Is it

properly

terminated on both ends?



>     bitrate 500000 sample-point 0.850

>     tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1

>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1

>     clock 10000000

>     re-started bus-errors arbit-lost error-warn error-pass bus-off

>     0          0          0          1          1          1

>     RX: bytes  packets  errors  dropped overrun mcast

>     101600     12700    0       0       0       0

>     TX: bytes  packets  errors  dropped carrier collsns

>     0          0        0       0       0       0

> if restart-ms is set it doesn't go down after sending a can message.



What do you mean? It will recover from bus-off after 1ms automatically.



> Also the device I' using is a Janus-RC intelligent terminus using busy

> box if you guys know anything about it and has two can networks and it

> is exactly the same for both so I don't know if that means it could

> still be a CAN_TX pin problem or not.



I don't think so but there are other electrical problem otherwise the

device

would not go bus-off. Does it work better at 125KB?



Wolfgang.

Re: can acknowledgment

[Michael Muldoon]

None of the devices are in listen only mode.  The can network is
properly terminated the other two devices are a pcan and a intrepid
fire which both show can traffic in their monitoring software.  When I
attempt  "# ip link set can0 type can restart" I receive the message
"RTNETLINK answers: Invalid argument". I ran it at 125Kb everything
was the same it can view messages as long as there are two other
devices on the network it can't send.



On Thu, Sep 5, 2013 at 9:45 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On Thu, 5 Sep 2013 08:47:44 -0400, Michael Muldoon <mbmuldoon07@gmail.com>
> wrote:
>> Before doing anything
>> can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>> mode DEFAULT qlen 10
>>     link/can
>>     can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 0
>>     bitrate 500000 sample-point 0.850
>>     tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1
>>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>     clock 10000000
>>
>> candump works fine as long as there are two other devices on the
>> network if just one there is nothing.
>
> Is the remaining "one" in listen-only mode?
>
>> after attempting to send a can message:
>> can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN
>> mode DEFAULT qlen 10
>>     link/can
>>     can <TRIPLE-SAMPLING> state BUS-OFF restart-ms 0
>
> Well, you entered BUS_OFF!!! You need first recover using:
>
>   # ip link set can0 type can restart
>
> See
> http://lxr.linux.no/#linux+v3.11/Documentation/networking/can.txt#L882.
>
> This means that there are electical problems on the CAN bus. Is it
> properly
> terminated on both ends?
>
>>     bitrate 500000 sample-point 0.850
>>     tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1
>>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>     clock 10000000
>>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>>     0          0          0          1          1          1
>>     RX: bytes  packets  errors  dropped overrun mcast
>>     101600     12700    0       0       0       0
>>     TX: bytes  packets  errors  dropped carrier collsns
>>     0          0        0       0       0       0
>> if restart-ms is set it doesn't go down after sending a can message.
>
> What do you mean? It will recover from bus-off after 1ms automatically.
>
>> Also the device I' using is a Janus-RC intelligent terminus using busy
>> box if you guys know anything about it and has two can networks and it
>> is exactly the same for both so I don't know if that means it could
>> still be a CAN_TX pin problem or not.
>
> I don't think so but there are other electrical problem otherwise the
> device
> would not go bus-off. Does it work better at 125KB?
>
> Wolfgang.
>

Re: can acknowledgment

[Wolfgang Grandegger]

On Thu, 5 Sep 2013 10:10:50 -0400, Michael Muldoon <mbmuldoon07@gmail.com>

wrote:

> None of the devices are in listen only mode.  The can network is

> properly terminated the other two devices are a pcan and a intrepid

> fire which both show can traffic in their monitoring software.  When I

> attempt  "# ip link set can0 type can restart" I receive the message

> "RTNETLINK answers: Invalid argument". I ran it at 125Kb everything



Was the device in bus-off state when you issued the command?



> was the same it can view messages as long as there are two other

> devices on the network it can't send.



Why did you enable TRIPLE-SAMPLING. It's unusual to use it. Try to disable

it.

You could also try adding "sjw 3" when you configure the device (with ip).



Wolfgang.



> 

> 

> 

> On Thu, Sep 5, 2013 at 9:45 AM, Wolfgang Grandegger <wg@grandegger.com>

> wrote:

>> On Thu, 5 Sep 2013 08:47:44 -0400, Michael Muldoon

>> <mbmuldoon07@gmail.com>

>> wrote:

>>> Before doing anything

>>> can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN

>>> mode DEFAULT qlen 10

>>>     link/can

>>>     can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 0

>>>     bitrate 500000 sample-point 0.850

>>>     tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1

>>>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1

>>>     clock 10000000

>>>

>>> candump works fine as long as there are two other devices on the

>>> network if just one there is nothing.

>>

>> Is the remaining "one" in listen-only mode?

>>

>>> after attempting to send a can message:

>>> can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN

>>> mode DEFAULT qlen 10

>>>     link/can

>>>     can <TRIPLE-SAMPLING> state BUS-OFF restart-ms 0

>>

>> Well, you entered BUS_OFF!!! You need first recover using:

>>

>>   # ip link set can0 type can restart

>>

>> See

>> http://lxr.linux.no/#linux+v3.11/Documentation/networking/can.txt#L882.

>>

>> This means that there are electical problems on the CAN bus. Is it

>> properly

>> terminated on both ends?

>>

>>>     bitrate 500000 sample-point 0.850

>>>     tq 100 prop-seg 8 phase-seg1 8 phase-seg2 3 sjw 1

>>>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1

>>>     clock 10000000

>>>     re-started bus-errors arbit-lost error-warn error-pass bus-off

>>>     0          0          0          1          1          1

>>>     RX: bytes  packets  errors  dropped overrun mcast

>>>     101600     12700    0       0       0       0

>>>     TX: bytes  packets  errors  dropped carrier collsns

>>>     0          0        0       0       0       0

>>> if restart-ms is set it doesn't go down after sending a can message.

>>

>> What do you mean? It will recover from bus-off after 1ms automatically.

>>

>>> Also the device I' using is a Janus-RC intelligent terminus using busy

>>> box if you guys know anything about it and has two can networks and it

>>> is exactly the same for both so I don't know if that means it could

>>> still be a CAN_TX pin problem or not.

>>

>> I don't think so but there are other electrical problem otherwise the

>> device

>> would not go bus-off. Does it work better at 125KB?

>>

>> Wolfgang.

>>

> --

> To unsubscribe from this list: send the line "unsubscribe linux-can" in

> the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: can acknowledgment

[Wolfgang Grandegger]

On 09/05/2013 07:17 PM, Michael Muldoon wrote:
> Linux version 3.2.20 (tomh@turbo_tom) (gcc version 4.5.3 (Buildroot
> 2012.05) ) and no I didn't do it myself it came setup.

Well, not that old but a few issues have been fixed in the meantime. Any
chance to switch to a more recent kernel version?

What hardware do you use? MCP2510 or MCP2515? Could you show the boot
log (output of "dmesg)?

Wolfgang,

> 
> On Thu, Sep 5, 2013 at 11:55 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> On Thu, 5 Sep 2013 11:33:19 -0400, Michael Muldoon <mbmuldoon07@gmail.com>
>> wrote:
>>> So I noticed that the can state is always UNKNOWN or DOWN could this
>>> be the problem?
>>> can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>>> mode DEFAULT qlen 10
>>>     link/can
>>>     can state BUS-OFF restart-ms 100
>>>     bitrate 125000 sample-point 0.875
>>>     tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>>>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>>     clock 10000000
>>>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>>>     0          0          0          327        327        0
>>>     RX: bytes  packets  errors  dropped overrun mcast
>>>     84592      10574    0       0       0       0
>>>     TX: bytes  packets  errors  dropped carrier collsns
>>>     0          0        0       0       0       0
>>> When I tried "# ip link set can0 type can reastart" can0 was definitely
>> on.
>>
>> Just to be sure: s/reastart/restart/
>>
>>> I tried change the settings you suggested still no changes.
>>
>> OK, what kernel version and distribution do you use?
>> Did you do the mc251x platform setup yourself?
>>
>> Wolfgang.
> 
> 

Re: can acknowledgment

[Michael Muldoon]

Here it is:

Linux version 3.2.20 (tomh@turbo_tom) (gcc version 4.5.3 (Buildroot
2012.05) ) #2 Wed Dec 5 14:33:28 CST 2012
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G20-EK
Memory policy: ECC disabled, Data cache writeback
AT91: Detected soc type: at91sam9g20
AT91: Detected soc subtype: Unknown
AT91: sram at 0x200000 of 0x4000 mapped at 0xfef74000
AT91: sram at 0x300000 of 0x4000 mapped at 0xfef70000
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat c03b4220, node_mem_map c03ce000
  Normal zone: 128 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 16256 pages, LIFO batch:3
Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: mem=64M console=ttyS0,115200 ubi.mtd=1
root=ubi0:rootfs rw rootfstype=ubifs
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 61036k/61036k available, 4500k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc4800000 - 0xfee00000   ( 934 MB)
    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc036cd20   (3476 kB)
      .init : 0xc036d000 - 0xc038f000   ( 136 kB)
      .data : 0xc0390000 - 0xc03b49e0   ( 147 kB)
       .bss : 0xc03b4a04 - 0xc03cdb88   ( 101 kB)
NR_IRQS:192
AT91: 96 gpio irqs in 3 banks
Console: colour dummy device 80x30
Calibrating delay loop... 197.01 BogoMIPS (lpj=985088)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
AT91: Power Management
AT91: Starting after general reset
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource pit
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 119
io scheduler noop registered (default)
atmel_usart.0: ttyS0 at MMIO 0xfffff200 (irq = 1) is a ATMEL_SERIAL
console [ttyS0] enabled
atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
atmel_usart.3: ttyS3 at MMIO 0xfffb8000 (irq = 8) is a ATMEL_SERIAL
atmel_usart.4: ttyS4 at MMIO 0xfffd0000 (irq = 23) is a ATMEL_SERIAL
atmel_usart.5: ttyS5 at MMIO 0xfffd4000 (irq = 24) is a ATMEL_SERIAL
brd: module loaded
loop: module loaded
atmel_nand atmel_nand: No DMA support for NAND access.
ONFI flash detected
ONFI param page 0 valid
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron MT29F1G08ABBDAH4)
Scanning device for bad blocks
Creating 3 MTD partitions on "atmel_nand":
0x000000000000-0x000000400000 : "Bootstrap"
0x000000400000-0x000004000000 : "Partition 1"
0x000004000000-0x000008000000 : "Partition 2"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: max. sequence number:       1124
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "Partition 1"
UBI: MTD device size:            60 MiB
UBI: number of good PEBs:        480
UBI: number of bad PEBs:         0
UBI: number of corrupted PEBs:   0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 480
UBI: number of PEBs reserved for bad PEB handling: 4
UBI: max/mean erase counter: 11/2
UBI: image sequence number:  1335236302
UBI: background thread "ubi_bgt0d" started, PID 353
atmel_spi atmel_spi.0: Atmel SPI Controller at 0xfffc8000 (irq 12)
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfffc4000 irq 21 (00:50:c2:9b:a8:8e)
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:00, irq=-1)
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 20, io mem 0x00500000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mousedev: PS/2 mouse device common for all mice
rtc-m41t94 spi0.3: rtc core: registered rtc-m41t94 as rtc0
rtc-m41t94: watchdog registered.
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 17
rtc-m41t94 spi0.3: setting system clock to 2013-09-05 19:35:20 UTC (1378409720)
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: file system size:   59480064 bytes (58086 KiB, 56 MiB, 461 LEBs)
UBIFS: journal size:       9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: lzo
UBIFS: reserved for root:  0 bytes (0 KiB)
VFS: Mounted root (ubifs filesystem) on device 0:12.
Freeing init memory: 136K
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
CAN device driver interface
can: raw protocol (rev 20090105)
mcp251x spi0.0: probed
mcp251x spi0.2: probed
mcp251x spi0.0: CNF: 0x01 0xff 0x02
mcp251x spi0.2: CNF: 0x01 0xff 0x02
eth0: link up (100/Full)

On Thu, Sep 5, 2013 at 3:24 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On 09/05/2013 07:17 PM, Michael Muldoon wrote:
>> Linux version 3.2.20 (tomh@turbo_tom) (gcc version 4.5.3 (Buildroot
>> 2012.05) ) and no I didn't do it myself it came setup.
>
> Well, not that old but a few issues have been fixed in the meantime. Any
> chance to switch to a more recent kernel version?
>
> What hardware do you use? MCP2510 or MCP2515? Could you show the boot
> log (output of "dmesg)?
>
> Wolfgang,
>
>>
>> On Thu, Sep 5, 2013 at 11:55 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> On Thu, 5 Sep 2013 11:33:19 -0400, Michael Muldoon <mbmuldoon07@gmail.com>
>>> wrote:
>>>> So I noticed that the can state is always UNKNOWN or DOWN could this
>>>> be the problem?
>>>> can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>>>> mode DEFAULT qlen 10
>>>>     link/can
>>>>     can state BUS-OFF restart-ms 100
>>>>     bitrate 125000 sample-point 0.875
>>>>     tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>>>>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>>>     clock 10000000
>>>>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>>>>     0          0          0          327        327        0
>>>>     RX: bytes  packets  errors  dropped overrun mcast
>>>>     84592      10574    0       0       0       0
>>>>     TX: bytes  packets  errors  dropped carrier collsns
>>>>     0          0        0       0       0       0
>>>> When I tried "# ip link set can0 type can reastart" can0 was definitely
>>> on.
>>>
>>> Just to be sure: s/reastart/restart/
>>>
>>>> I tried change the settings you suggested still no changes.
>>>
>>> OK, what kernel version and distribution do you use?
>>> Did you do the mc251x platform setup yourself?
>>>
>>> Wolfgang.
>>
>>
>

Re: can acknowledgment

[Michael Muldoon]

And the hardware is mcp2515

On Thu, Sep 5, 2013 at 3:24 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On 09/05/2013 07:17 PM, Michael Muldoon wrote:
>> Linux version 3.2.20 (tomh@turbo_tom) (gcc version 4.5.3 (Buildroot
>> 2012.05) ) and no I didn't do it myself it came setup.
>
> Well, not that old but a few issues have been fixed in the meantime. Any
> chance to switch to a more recent kernel version?
>
> What hardware do you use? MCP2510 or MCP2515? Could you show the boot
> log (output of "dmesg)?
>
> Wolfgang,
>
>>
>> On Thu, Sep 5, 2013 at 11:55 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> On Thu, 5 Sep 2013 11:33:19 -0400, Michael Muldoon <mbmuldoon07@gmail.com>
>>> wrote:
>>>> So I noticed that the can state is always UNKNOWN or DOWN could this
>>>> be the problem?
>>>> can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>>>> mode DEFAULT qlen 10
>>>>     link/can
>>>>     can state BUS-OFF restart-ms 100
>>>>     bitrate 125000 sample-point 0.875
>>>>     tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>>>>     mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>>>     clock 10000000
>>>>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>>>>     0          0          0          327        327        0
>>>>     RX: bytes  packets  errors  dropped overrun mcast
>>>>     84592      10574    0       0       0       0
>>>>     TX: bytes  packets  errors  dropped carrier collsns
>>>>     0          0        0       0       0       0
>>>> When I tried "# ip link set can0 type can reastart" can0 was definitely
>>> on.
>>>
>>> Just to be sure: s/reastart/restart/
>>>
>>>> I tried change the settings you suggested still no changes.
>>>
>>> OK, what kernel version and distribution do you use?
>>> Did you do the mc251x platform setup yourself?
>>>
>>> Wolfgang.
>>
>>
>

Re: can acknowledgment

[Wolfgang Grandegger]

On 09/05/2013 09:45 PM, Michael Muldoon wrote:
> Here it is:
> 
> Linux version 3.2.20 (tomh@turbo_tom) (gcc version 4.5.3 (Buildroot
> 2012.05) ) #2 Wed Dec 5 14:33:28 CST 2012
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Atmel AT91SAM9G20-EK

Even if reported, this seems not to be a Atmel AT91SAM9G20-EK board.
What do you find in "arch/arm/mach-at91/board-sam9g20ek.c".

...
> can: controller area network core (rev 20090105 abi 8)
> NET: Registered protocol family 29
> CAN device driver interface
> can: raw protocol (rev 20090105)
> mcp251x spi0.0: probed
> mcp251x spi0.2: probed
> mcp251x spi0.0: CNF: 0x01 0xff 0x02
> mcp251x spi0.2: CNF: 0x01 0xff 0x02

Strange. The latter two line should not show up before the devices are
opened (with ifconfig or ip.. Also "drivers/net/can/mcp251x.c" seems to
be special.

And how to you configure and start the CAN devices?

Wolfgang.