read() question from newbie

read() question from newbie

[Michael Economides]

I am trying to use the cantest program to read.  It just blocks on the
read, and stays there forever.

 I can see on my scope there are can messages coming across the bus (from a
different microcontroller attached to the bus).

I have already verified I can write using cantest.

In other words, this works:  ./cantest can0 1F334455#1122334455667788

But this doesn't:  ./cantest can0

What could cause this?  Improper configuration is my suspicion.  Is it
possible these messages are being filtered somehow?  I am using MPC5121E
micro.

Any help would be appreciated.

Thanks,

--Mike

Re: read() question from newbie

[Oliver Hartkopp]

On 02.03.2012 23:09, Michael Economides wrote:

> I am trying to use the cantest program to read.  It just blocks on the
> read, and stays there forever.
> 
>  I can see on my scope there are can messages coming across the bus (from a
> different microcontroller attached to the bus).
> 
> I have already verified I can write using cantest.
> 
> In other words, this works:  ./cantest can0 1F334455#1122334455667788
> 
> But this doesn't:  ./cantest can0
> 


Hello Mike,

where is this tool 'cantest' from?

I don't know it either from the SocketCAN utils

https://gitorious.org/linux-can/can-utils

nor from the Pengutronix canutils

http://git.pengutronix.de/?p=tools/canutils.git;a=summary

Maybe you can alternatively try the SocketCAN utils to test.

Regards,
Oliver

Re: read() question from newbie

[Michael Economides]

On Sat, Mar 3, 2012 at 1:05 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> On 02.03.2012 23:09, Michael Economides wrote:
>
>> I am trying to use the cantest program to read.  It just blocks on the
>> read, and stays there forever.
>>
>>  I can see on my scope there are can messages coming across the bus (from a
>> different microcontroller attached to the bus).
>>
>> I have already verified I can write using cantest.
>>
>> In other words, this works:  ./cantest can0 1F334455#1122334455667788
>>
>> But this doesn't:  ./cantest can0
>>
>
>
> Hello Mike,
>
> where is this tool 'cantest' from?
>
> I don't know it either from the SocketCAN utils
>
> https://gitorious.org/linux-can/can-utils
>
> nor from the Pengutronix canutils
>
> http://git.pengutronix.de/?p=tools/canutils.git;a=summary
>
> Maybe you can alternatively try the SocketCAN utils to test.
>
> Regards,
> Oliver

Hi Oliver,

Thanks for your reply.

"cantest" is a slightly modified version of cansend.c from the link
above.  it does a read() as well as a write().

  basically what i'm seeing is CAN frames (standard format) coming
across the bus, but read() call just blocks as if nothing is there.

A coworker of mine reports that the read() is responding only to
extended frame format.

Can you provide any insight into this?  Specifically, how do we
configure our CAN socket to respond to extended vs. standard frames?
We would like to use standard, not extended.

Thanks,

Mike

Re: read() question from newbie

[Oliver Hartkopp]

On 05.03.2012 18:49, Michael Economides wrote:

> On Sat, Mar 3, 2012 at 1:05 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>> On 02.03.2012 23:09, Michael Economides wrote:
>>
>>> I am trying to use the cantest program to read.  It just blocks on the
>>> read, and stays there forever.
>>>
>>>  I can see on my scope there are can messages coming across the bus (from a
>>> different microcontroller attached to the bus).
>>>
>>> I have already verified I can write using cantest.
>>>
>>> In other words, this works:  ./cantest can0 1F334455#1122334455667788
>>>
>>> But this doesn't:  ./cantest can0
>>>
>>
>>
>> Hello Mike,
>>
>> where is this tool 'cantest' from?
>>
>> I don't know it either from the SocketCAN utils
>>
>> https://gitorious.org/linux-can/can-utils
>>
>> nor from the Pengutronix canutils
>>
>> http://git.pengutronix.de/?p=tools/canutils.git;a=summary
>>
>> Maybe you can alternatively try the SocketCAN utils to test.
>>
>> Regards,
>> Oliver
> 
> Hi Oliver,
> 
> Thanks for your reply.
> 
> "cantest" is a slightly modified version of cansend.c from the link
> above.  it does a read() as well as a write().
> 
>   basically what i'm seeing is CAN frames (standard format) coming
> across the bus, but read() call just blocks as if nothing is there.
> 
> A coworker of mine reports that the read() is responding only to
> extended frame format.
> 
> Can you provide any insight into this?  Specifically, how do we
> configure our CAN socket to respond to extended vs. standard frames?
> We would like to use standard, not extended.


Please just type

	candump any

to check whether you really get anything in your system.

Using 'candump any' without any additional provided filter definitions
displays anything (EFF&SFF) which is received on the host.

Don't know what you've 'slightly modified' :-)

Therefore check with a unmodified candump first.

Regards,
Oliver

Re: read() question from newbie

[Oliver Hartkopp]

On 05.03.2012 23:19, Oliver Hartkopp wrote:

> On 05.03.2012 18:49, Michael Economides wrote:
> 
>> On Sat, Mar 3, 2012 at 1:05 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>> On 02.03.2012 23:09, Michael Economides wrote:
>>>
>>>> I am trying to use the cantest program to read.  It just blocks on the
>>>> read, and stays there forever.
>>>>
>>>>  I can see on my scope there are can messages coming across the bus (from a
>>>> different microcontroller attached to the bus).
>>>>
>>>> I have already verified I can write using cantest.
>>>>
>>>> In other words, this works:  ./cantest can0 1F334455#1122334455667788
>>>>
>>>> But this doesn't:  ./cantest can0
>>>>
>>>
>>>
>>> Hello Mike,
>>>
>>> where is this tool 'cantest' from?
>>>
>>> I don't know it either from the SocketCAN utils
>>>
>>> https://gitorious.org/linux-can/can-utils
>>>
>>> nor from the Pengutronix canutils
>>>
>>> http://git.pengutronix.de/?p=tools/canutils.git;a=summary
>>>
>>> Maybe you can alternatively try the SocketCAN utils to test.
>>>
>>> Regards,
>>> Oliver
>>
>> Hi Oliver,
>>
>> Thanks for your reply.
>>
>> "cantest" is a slightly modified version of cansend.c from the link
>> above.  it does a read() as well as a write().


Ha, ha - did you read that comment in cansend?

    /* disable default receive filter on this RAW socket */
    /* This is obsolete as we do not read from the socket at all, but for */
    /* this reason we can remove the receive list in the Kernel to save a */
    /* little (really a very little!) CPU usage.                          */
    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);


>>
>>   basically what i'm seeing is CAN frames (standard format) coming
>> across the bus, but read() call just blocks as if nothing is there.
>>
>> A coworker of mine reports that the read() is responding only to
>> extended frame format.
>>
>> Can you provide any insight into this?  Specifically, how do we
>> configure our CAN socket to respond to extended vs. standard frames?
>> We would like to use standard, not extended.
> 
> 
> Please just type
> 
> 	candump any
> 
> to check whether you really get anything in your system.
> 
> Using 'candump any' without any additional provided filter definitions
> displays anything (EFF&SFF) which is received on the host.
> 
> Don't know what you've 'slightly modified' :-)
> 
> Therefore check with a unmodified candump first.
> 
> Regards,
> Oliver
> --
> 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: read() question from newbie

[Michael Economides]

On Mon, Mar 5, 2012 at 2:22 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> On 05.03.2012 23:19, Oliver Hartkopp wrote:
>
>> On 05.03.2012 18:49, Michael Economides wrote:
>>
>>> On Sat, Mar 3, 2012 at 1:05 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>>> On 02.03.2012 23:09, Michael Economides wrote:
>>>>
>>>>> I am trying to use the cantest program to read.  It just blocks on the
>>>>> read, and stays there forever.
>>>>>
>>>>>  I can see on my scope there are can messages coming across the bus (from a
>>>>> different microcontroller attached to the bus).
>>>>>
>>>>> I have already verified I can write using cantest.
>>>>>
>>>>> In other words, this works:  ./cantest can0 1F334455#1122334455667788
>>>>>
>>>>> But this doesn't:  ./cantest can0
>>>>>
>>>>
>>>>
>>>> Hello Mike,
>>>>
>>>> where is this tool 'cantest' from?
>>>>
>>>> I don't know it either from the SocketCAN utils
>>>>
>>>> https://gitorious.org/linux-can/can-utils
>>>>
>>>> nor from the Pengutronix canutils
>>>>
>>>> http://git.pengutronix.de/?p=tools/canutils.git;a=summary
>>>>
>>>> Maybe you can alternatively try the SocketCAN utils to test.
>>>>
>>>> Regards,
>>>> Oliver
>>>
>>> Hi Oliver,
>>>
>>> Thanks for your reply.
>>>
>>> "cantest" is a slightly modified version of cansend.c from the link
>>> above.  it does a read() as well as a write().
>
>
> Ha, ha - did you read that comment in cansend?
>
>    /* disable default receive filter on this RAW socket */
>    /* This is obsolete as we do not read from the socket at all, but for */
>    /* this reason we can remove the receive list in the Kernel to save a */
>    /* little (really a very little!) CPU usage.                          */
>    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);
>
>
>>>
>>>   basically what i'm seeing is CAN frames (standard format) coming
>>> across the bus, but read() call just blocks as if nothing is there.
>>>
>>> A coworker of mine reports that the read() is responding only to
>>> extended frame format.
>>>
>>> Can you provide any insight into this?  Specifically, how do we
>>> configure our CAN socket to respond to extended vs. standard frames?
>>> We would like to use standard, not extended.
>>
>>
>> Please just type
>>
>>       candump any
>>
>> to check whether you really get anything in your system.
>>
>> Using 'candump any' without any additional provided filter definitions
>> displays anything (EFF&SFF) which is received on the host.
>>
>> Don't know what you've 'slightly modified' :-)
>>
>> Therefore check with a unmodified candump first.
>>
>> Regards,
>> Oliver
>> --
>> 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
>
>

Hi Oliver,

Yes, we removed that line of code with the filtering in cansend.c

I ran "candump any", it just sits there, nothing is printed to the
screen.  So it looks like it thinks nothing is coming across on the
CAN bus(?)  But like I already stated, on the scope I can see some CAN
frames being sent to me.

I will be using a Can analyzer tools today, to further my investigation.

Bascially, all I was asking of you is what could cause read() to wait
forever... or candump to just sit there and wait?

Maybe the CAN data being sent is not valid (garbage)?

Thanks again for your help!

Mike

Re: read() question from newbie

[Oliver Hartkopp]

On 06.03.2012 19:53, Michael Economides wrote:


> Yes, we removed that line of code with the filtering in cansend.c


fine.

> I ran "candump any", it just sits there, nothing is printed to the
> screen.  So it looks like it thinks nothing is coming across on the
> CAN bus(?)  But like I already stated, on the scope I can see some CAN
> frames being sent to me.


You can check either

cat /proc/net/dev

and

cat /proc/net/can/stats

to see if really any CAN frame entered your system.

I assume there is a CAN bus problem:

- wiring (CAN_L/CAN_H)
- correct CAN termination (2x 120 Ohms)
- different bitrate

> 
> I will be using a Can analyzer tools today, to further my investigation.


Adding some more CAN nodes can help too - so adding another tool and testing
is always a good idea.

> 
> Bascially, all I was asking of you is what could cause read() to wait
> forever... or candump to just sit there and wait?


Well yes. It does a blocking read to get and print receive CAN frames. What do
you expect?

> Maybe the CAN data being sent is not valid (garbage)?


Yes. Please check the three points mentioned above.

Best regards,
Oliver

Re: read() question from newbie

[Michael Economides]

Hi Oliver,

It has been some time since I emailed you about this.  I was put onto
other work, but now I have come back to it.

If you will recall, I was trying to send/receive some CAN frames, but
was not seeing any come into my can test program.  However, on the
oscilloscope I do see CAN activity on the bus....

You suggested:

>
> You can check either
>
> cat /proc/net/dev
>
> and
>
> cat /proc/net/can/stats
>
> to see if really any CAN frame entered your system.


I did this.  Here is the output:

# cat /proc/net/can/stats

        0 transmitted frames (TXF)
        0 received frames (RXF)
        0 matched frames (RXMF)

        0 % total match ratio (RXMR)
        0 frames/s total tx rate (TXR)
        0 frames/s total rx rate (RXR)

        0 % current match ratio (CRXMR)
        0 frames/s current tx rate (CTXR)
        0 frames/s current rx rate (CRXR)

        0 % max match ratio (MRXMR)
        0 frames/s max tx rate (MTXR)
        0 frames/s max rx rate (MRXR)

        0 current receive list entries (CRCV)
        1 maximum receive list entries (MRCV)


and...


# cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed
multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:     988      11    0    0    0     0          0         0
988      11    0    0    0     0       0          0
  eth0:       0       0    0    0    0     0          0         0
  0       0    0    0    0     0       0          0
  can0:       0       0    0    0    0     0          0         0
  0       0    0    0    0     0       0          0
  can1:       0       0    0    0    0     0          0         0
  0       0    0    0    0     0       0          0
  can2:       0       0    0    0    0     0          0         0
  0       0    0    0    0     0       0          0
  can3:       0       0    0    0    0     0          0         0
  0       0    0    0    0     0       0          0


>
> I assume there is a CAN bus problem:
>
> - wiring (CAN_L/CAN_H)
> - correct CAN termination (2x 120 Ohms)
> - different bitrate
>

I think you are right, but I have checked that, it looks ok.  I will
check again.

I am using a PCAN USB adapter, and the PCAN software says there is an
"acknowledge error" when it sends a frame to my Linux board.

When the Linux board tries to send a frame to PCAN, the PCAN software
says "form error acknowledge delimiter".

It seems this is the same error in both cases, just worded differently.

In your opinion, is this most likely a hardware issue?  Or is there
still some way I could be doing something wrong at the software level?

I can send you any more info you need, if it would help.

Thanks for all your time...

Regards,

Michael

Re: read() question from newbie

[Oliver Hartkopp]

On 17.04.2012 06:16, Michael Economides wrote:


>>
>> I assume there is a CAN bus problem:
>>
>> - wiring (CAN_L/CAN_H)
>> - correct CAN termination (2x 120 Ohms)
>> - different bitrate
>>
> 
> I think you are right, but I have checked that, it looks ok.  I will
> check again.
> 
> I am using a PCAN USB adapter, and the PCAN software says there is an
> "acknowledge error" when it sends a frame to my Linux board.


This is an indication for a missing counterpart CAN node:

- Wrong connection wiring
- Wrong termination
- Wrong bitrate

> 
> When the Linux board tries to send a frame to PCAN, the PCAN software
> says "form error acknowledge delimiter".
> 
> It seems this is the same error in both cases, just worded differently.


Yes. But this means the same regarding the obvious problems.

> 
> In your opinion, is this most likely a hardware issue?  Or is there
> still some way I could be doing something wrong at the software level?


Did you swap CAN_H / CAN_L ??

It's definitely one of the three points above. No SW problem ...

Try to add a third CAN node - if you have one.

Regards,
Oliver

Re: read() question from newbie

[Michael Economides]

Hi Oliver,

Looking on my scope, it does seem like the baudrate is a little off.

Here are the commands I use to set up my CAN interface on my Linux board:

insmod -m candev;
insmod -m mscan-mpc52xx;
insmod -m can;
insmod -m can-raw
ifconfig can0 up;

./cantest can0 baud 1000000;

This "cantest" program uses:

 ifr.ifr_ifru.ifru_ivalue = baudrate;
ret = ioctl(s, SIOCSCANBAUDRATE, &ifr);

to set the baudrate.  But it seems from reading other discussions,
that this is not the correct way to set baud rate.

I am using the MPC5121 from Freescale, in case that is relevant.

Thanks,

Mike


On Mon, Apr 16, 2012 at 11:08 PM, Oliver Hartkopp
<socketcan@hartkopp.net> wrote:
> On 17.04.2012 06:16, Michael Economides wrote:
>
>
>>>
>>> I assume there is a CAN bus problem:
>>>
>>> - wiring (CAN_L/CAN_H)
>>> - correct CAN termination (2x 120 Ohms)
>>> - different bitrate
>>>
>>
>> I think you are right, but I have checked that, it looks ok.  I will
>> check again.
>>
>> I am using a PCAN USB adapter, and the PCAN software says there is an
>> "acknowledge error" when it sends a frame to my Linux board.
>
>
> This is an indication for a missing counterpart CAN node:
>
> - Wrong connection wiring
> - Wrong termination
> - Wrong bitrate
>
>>
>> When the Linux board tries to send a frame to PCAN, the PCAN software
>> says "form error acknowledge delimiter".
>>
>> It seems this is the same error in both cases, just worded differently.
>
>
> Yes. But this means the same regarding the obvious problems.
>
>>
>> In your opinion, is this most likely a hardware issue?  Or is there
>> still some way I could be doing something wrong at the software level?
>
>
> Did you swap CAN_H / CAN_L ??
>
> It's definitely one of the three points above. No SW problem ...
>
> Try to add a third CAN node - if you have one.
>
> Regards,
> Oliver

Re: read() question from newbie

[Wolfgang Grandegger]

Hi Michael,

On 04/18/2012 10:13 PM, Michael Economides wrote:
> Hi Oliver,
> 
> Looking on my scope, it does seem like the baudrate is a little off.
> 
> Here are the commands I use to set up my CAN interface on my Linux board:
> 
> insmod -m candev;

Oops, you are using a very very old version of insmod. Are you using
Linux 2.4.x? I do remember using "-m" with old Linux 2.4 distributions.

> insmod -m mscan-mpc52xx;
> insmod -m can;
> insmod -m can-raw
> ifconfig can0 up;
> 
> ./cantest can0 baud 1000000;
> 
> This "cantest" program uses:
> 
>  ifr.ifr_ifru.ifru_ivalue = baudrate;
> ret = ioctl(s, SIOCSCANBAUDRATE, &ifr);
> 
> to set the baudrate.  But it seems from reading other discussions,
> that this is not the correct way to set baud rate.

That's right, in case you are using a recent kernel version.

> I am using the MPC5121 from Freescale, in case that is relevant.

What Linux kernel version do you use? Where did you get the drivers
above from?

Wolfgang.

> On Mon, Apr 16, 2012 at 11:08 PM, Oliver Hartkopp
> <socketcan@hartkopp.net> wrote:
>> On 17.04.2012 06:16, Michael Economides wrote:
>>
>>
>>>>
>>>> I assume there is a CAN bus problem:
>>>>
>>>> - wiring (CAN_L/CAN_H)
>>>> - correct CAN termination (2x 120 Ohms)
>>>> - different bitrate
>>>>
>>>
>>> I think you are right, but I have checked that, it looks ok.  I will
>>> check again.
>>>
>>> I am using a PCAN USB adapter, and the PCAN software says there is an
>>> "acknowledge error" when it sends a frame to my Linux board.
>>
>>
>> This is an indication for a missing counterpart CAN node:
>>
>> - Wrong connection wiring
>> - Wrong termination
>> - Wrong bitrate
>>
>>>
>>> When the Linux board tries to send a frame to PCAN, the PCAN software
>>> says "form error acknowledge delimiter".
>>>
>>> It seems this is the same error in both cases, just worded differently.
>>
>>
>> Yes. But this means the same regarding the obvious problems.
>>
>>>
>>> In your opinion, is this most likely a hardware issue?  Or is there
>>> still some way I could be doing something wrong at the software level?
>>
>>
>> Did you swap CAN_H / CAN_L ??
>>
>> It's definitely one of the three points above. No SW problem ...
>>
>> Try to add a third CAN node - if you have one.
>>
>> Regards,
>> Oliver
> --
> 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: read() question from newbie

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

On 04/18/2012 10:13 PM, Michael Economides wrote:
> Hi Oliver,
> 
> Looking on my scope, it does seem like the baudrate is a little off.
> 
> Here are the commands I use to set up my CAN interface on my Linux board:
> 
> insmod -m candev;
> insmod -m mscan-mpc52xx;
> insmod -m can;
> insmod -m can-raw
> ifconfig can0 up;

With mainline it's not possible to ifup an interface without setting the
bitrate first.

> ./cantest can0 baud 1000000;
> 
> This "cantest" program uses:
> 
>  ifr.ifr_ifru.ifru_ivalue = baudrate;
> ret = ioctl(s, SIOCSCANBAUDRATE, &ifr);
> 
> to set the baudrate.  But it seems from reading other discussions,
> that this is not the correct way to set baud rate.

This ioctl isn't supported anymore, as Wolfgang pointed out you're
probably not using a mainline socketcan.

> I am using the MPC5121 from Freescale, in case that is relevant.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: read() question from newbie

[Michael Economides]

On Wed, Apr 18, 2012 at 1:59 PM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 04/18/2012 10:13 PM, Michael Economides wrote:
>> Hi Oliver,
>>
>> Looking on my scope, it does seem like the baudrate is a little off.
>>
>> Here are the commands I use to set up my CAN interface on my Linux board:
>>
>> insmod -m candev;
>> insmod -m mscan-mpc52xx;
>> insmod -m can;
>> insmod -m can-raw
>> ifconfig can0 up;
>
> With mainline it's not possible to ifup an interface without setting the
> bitrate first.
>
>> ./cantest can0 baud 1000000;
>>
>> This "cantest" program uses:
>>
>>  ifr.ifr_ifru.ifru_ivalue = baudrate;
>> ret = ioctl(s, SIOCSCANBAUDRATE, &ifr);
>>
>> to set the baudrate.  But it seems from reading other discussions,
>> that this is not the correct way to set baud rate.
>
> This ioctl isn't supported anymore, as Wolfgang pointed out you're
> probably not using a mainline socketcan.
>
>> I am using the MPC5121 from Freescale, in case that is relevant.
>
> Marc
>
> --
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

Ok thanks Marc.

I'm using Linux BSP for Freescale MPC5121EADS.  It is quite old
(2009/06/02).  It was designed for the Freescale ADS5121 evaluation
board.  The board I'm using is similar.

I suppose the task now is to update this BSP with the latest socketCAN stuff?

-Mike

Re: read() question from newbie

[Michael Economides]

Hi Wolfgang,

I checked and the Freescale BSP I'm using is based on Linux version
2.6.24.7-rt21

Thanks,

Mike


On Wed, Apr 18, 2012 at 1:32 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hi Michael,
>
> On 04/18/2012 10:13 PM, Michael Economides wrote:
>> Hi Oliver,
>>
>> Looking on my scope, it does seem like the baudrate is a little off.
>>
>> Here are the commands I use to set up my CAN interface on my Linux board:
>>
>> insmod -m candev;
>
> Oops, you are using a very very old version of insmod. Are you using
> Linux 2.4.x? I do remember using "-m" with old Linux 2.4 distributions.
>
>> insmod -m mscan-mpc52xx;
>> insmod -m can;
>> insmod -m can-raw
>> ifconfig can0 up;
>>
>> ./cantest can0 baud 1000000;
>>
>> This "cantest" program uses:
>>
>>  ifr.ifr_ifru.ifru_ivalue = baudrate;
>> ret = ioctl(s, SIOCSCANBAUDRATE, &ifr);
>>
>> to set the baudrate.  But it seems from reading other discussions,
>> that this is not the correct way to set baud rate.
>
> That's right, in case you are using a recent kernel version.
>
>> I am using the MPC5121 from Freescale, in case that is relevant.
>
> What Linux kernel version do you use? Where did you get the drivers
> above from?
>
> Wolfgang.
>
>> On Mon, Apr 16, 2012 at 11:08 PM, Oliver Hartkopp
>> <socketcan@hartkopp.net> wrote:
>>> On 17.04.2012 06:16, Michael Economides wrote:
>>>
>>>
>>>>>
>>>>> I assume there is a CAN bus problem:
>>>>>
>>>>> - wiring (CAN_L/CAN_H)
>>>>> - correct CAN termination (2x 120 Ohms)
>>>>> - different bitrate
>>>>>
>>>>
>>>> I think you are right, but I have checked that, it looks ok.  I will
>>>> check again.
>>>>
>>>> I am using a PCAN USB adapter, and the PCAN software says there is an
>>>> "acknowledge error" when it sends a frame to my Linux board.
>>>
>>>
>>> This is an indication for a missing counterpart CAN node:
>>>
>>> - Wrong connection wiring
>>> - Wrong termination
>>> - Wrong bitrate
>>>
>>>>
>>>> When the Linux board tries to send a frame to PCAN, the PCAN software
>>>> says "form error acknowledge delimiter".
>>>>
>>>> It seems this is the same error in both cases, just worded differently.
>>>
>>>
>>> Yes. But this means the same regarding the obvious problems.
>>>
>>>>
>>>> In your opinion, is this most likely a hardware issue?  Or is there
>>>> still some way I could be doing something wrong at the software level?
>>>
>>>
>>> Did you swap CAN_H / CAN_L ??
>>>
>>> It's definitely one of the three points above. No SW problem ...
>>>
>>> Try to add a third CAN node - if you have one.
>>>
>>> Regards,
>>> Oliver
>> --
>> 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: read() question from newbie

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On 04/18/2012 11:21 PM, Michael Economides wrote:
> I'm using Linux BSP for Freescale MPC5121EADS.  It is quite old
> (2009/06/02).  It was designed for the Freescale ADS5121 evaluation
> board.  The board I'm using is similar.
> 
> I suppose the task now is to update this BSP with the latest socketCAN stuff?

Yes, this basically means updating to latest kernel. Drop me a note of
you need help.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: read() question from newbie

[Wolfgang Grandegger]

On 04/19/2012 01:10 AM, Michael Economides wrote:
> Hi Wolfgang,
> 
> I checked and the Freescale BSP I'm using is based on Linux version
> 2.6.24.7-rt21

Do you need rt? Anyway, IIRC, the MPC5121EADS board is supported by the
mainline kernel:

http://lxr.linux.no/#linux+v3.3.2/arch/powerpc/boot/dts/mpc5121ads.dts

There is no need to use the old kernel from Freescale's LTIB
distribution, which uses a special and old Socket-CAN implementation.

Wolfgang.


> On Wed, Apr 18, 2012 at 1:32 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Hi Michael,
>>
>> On 04/18/2012 10:13 PM, Michael Economides wrote:
>>> Hi Oliver,
>>>
>>> Looking on my scope, it does seem like the baudrate is a little off.
>>>
>>> Here are the commands I use to set up my CAN interface on my Linux board:
>>>
>>> insmod -m candev;
>>
>> Oops, you are using a very very old version of insmod. Are you using
>> Linux 2.4.x? I do remember using "-m" with old Linux 2.4 distributions.
>>
>>> insmod -m mscan-mpc52xx;
>>> insmod -m can;
>>> insmod -m can-raw
>>> ifconfig can0 up;
>>>
>>> ./cantest can0 baud 1000000;
>>>
>>> This "cantest" program uses:
>>>
>>>  ifr.ifr_ifru.ifru_ivalue = baudrate;
>>> ret = ioctl(s, SIOCSCANBAUDRATE, &ifr);
>>>
>>> to set the baudrate.  But it seems from reading other discussions,
>>> that this is not the correct way to set baud rate.
>>
>> That's right, in case you are using a recent kernel version.
>>
>>> I am using the MPC5121 from Freescale, in case that is relevant.
>>
>> What Linux kernel version do you use? Where did you get the drivers
>> above from?
>>
>> Wolfgang.
>>
>>> On Mon, Apr 16, 2012 at 11:08 PM, Oliver Hartkopp
>>> <socketcan@hartkopp.net> wrote:
>>>> On 17.04.2012 06:16, Michael Economides wrote:
>>>>
>>>>
>>>>>>
>>>>>> I assume there is a CAN bus problem:
>>>>>>
>>>>>> - wiring (CAN_L/CAN_H)
>>>>>> - correct CAN termination (2x 120 Ohms)
>>>>>> - different bitrate
>>>>>>
>>>>>
>>>>> I think you are right, but I have checked that, it looks ok.  I will
>>>>> check again.
>>>>>
>>>>> I am using a PCAN USB adapter, and the PCAN software says there is an
>>>>> "acknowledge error" when it sends a frame to my Linux board.
>>>>
>>>>
>>>> This is an indication for a missing counterpart CAN node:
>>>>
>>>> - Wrong connection wiring
>>>> - Wrong termination
>>>> - Wrong bitrate
>>>>
>>>>>
>>>>> When the Linux board tries to send a frame to PCAN, the PCAN software
>>>>> says "form error acknowledge delimiter".
>>>>>
>>>>> It seems this is the same error in both cases, just worded differently.
>>>>
>>>>
>>>> Yes. But this means the same regarding the obvious problems.
>>>>
>>>>>
>>>>> In your opinion, is this most likely a hardware issue?  Or is there
>>>>> still some way I could be doing something wrong at the software level?
>>>>
>>>>
>>>> Did you swap CAN_H / CAN_L ??
>>>>
>>>> It's definitely one of the three points above. No SW problem ...
>>>>
>>>> Try to add a third CAN node - if you have one.
>>>>
>>>> Regards,
>>>> Oliver
>>> --
>>> 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
>>>
>>>
>>
> 
>