Hi, I got a problem on MX53 CAN bitrate setting. It seems the bitrate can not be set. I tried "canconfig" but got following result:
# canconfig can0 bitrate 125000
RTNETLINK answers: Operation not supported
failed to set bitrate of can0 to 125000
When I ran "cat /sys/devices/platform/FlexCAN.0/bitrate", it said the bitrate is 282240. But this number looks like not a "standard" number.
When I connect two MX53 boards and run candump on one of the board, run cansend on another board, the test succeeded. But this works only between two MX53 boards.
I tried to set bitrate by "echo 125000 > /sys/devices/platform/FlexCAN.0/bitrate". I watched the waveform by an oscilloscope and found the bitrate did not change.
Is there any way for changing the bitrate of MX53 CAN?
The BSP I used is MX53 Android R10.3. The board is custom board based on MX53-SMD.
Thanks.
Hello Frank,
i don't know much about Android, but under Linux changing the CAN bitrate requires the package iproute2. The necessary call is:
ip link set can0 type can bitrate 125000
For Linux + CAN specific questions their is also a mailing list with an archive:
Hi Stefan,
Thanks for reply.
I tried the "ip" command but got error messages:
root@freescale ~$ ip link set can0 type can bitrate 125000
ip: either "dev" is duplicate, or "type" is garbage
By Google it is because the "ip" command is an applet of busybox and it doesn't work.
Then I downloaded and cross-compiled the iproute2 package and got the following message:
root@freescale ~$ /ip link set can0 type can bitrate 125000
RTNETLINK answers: Operation not supported
So the error is similar to canconfig. I guess there may be something wrong in kernel/driver configuration.
Does FSL or FSL customer have successful experience in setting MX53 CAN bitrate?
The above tests were performed on Linux.
Did you manage to resolve this problem? I'm seeing something very similar.
Hi Shane,
Yes, I have resolved the problem. We can use the CAN sysfs attribute to change the bitrate, for example:
"echo 125000 > /sys/devices/platform/FlexCAN.0/bitrate"
However, the clock setting for MX53 CAN is incorrect in MX53 Android release R10.3. To fix this problem, please refer to the following link:
Dear Frank,
I have the same problem in setting bitrate in CAN using FlexCAN driver. I did same thing as you said
root@mx28evk ~$ ip link set can0 type can bitrate 125000
RTNETLINK answers: Operation not supported
root@mx28evk ~$ ip link set can0 type can bitrate 125000
RTNETLINK answers: Operation not supported
root@mx28evk ~$ echo 125000 > /sys/devices/platform/FlexCAN.0/bitrate
root@mx28evk ~$ cat /sys/devices/platform/FlexCAN.0/bitrate
500000
root@mx28evk ~$
but bitrate is not getting changed even after writing into CAN sysfs attribute. Please help me to resolve this issue and let me know what are the things I have to change in kernel menuconfig.
Note : I am working on imx28 EVK board with Linux 2.6.35.
Frank,
Thanks for reply. I think I'm seeing something different. I already made the changes to fix the parent clock issue, although in our case, we're using the IPG clock (running at 66MHz). When I made this change, the baud rate measured on the scope matched the current setting.
I get an error msg when I use the sysfs method to set the baud rate:
The bitrate 125000 can't supported with clock rate of 66666666.
When I tried canconfig, I got the same error msg that you originally saw. Did you ever get canconfig to work for you?
We're using Android R10.2 for iMX53 ARD.
Regards,
Shane.
Hi Shane,
No, canconfig didn't work for me. I use sysfs method to changed the bitrate.
I didn't see the error like what you got when use sysfs to changed the bitrate. Perhaps it is because the BSP versions we used are different. The BSP I worked on is MX53 SMD Android R10.3.
Frank,
Just reporting back for completeness, in case anyone else runs into this problem.
I changed my code to use the LP_APM clock as the parent clock for the CAN modules, and I can now set the baud rate using the sysfs method. Looks like this is the default clock in the BSP, so using the IPG clock was a bad idea.
Thanks for your help,
Shane.