i.MX28 CAN frame transmission order problem

[JamesAttewell]

Hi All,

I am having a problem with the order that CAN frames are transmitted from the MX28's CAN bus. When I send more than 10 or so messages one after the other they don't always appear on the CAN bus in that order when read from another node. Has anyone else seen this problem before or got any suggestions?

Thanks for your help/advice in advance

James

[samuelsalas]

And this might be helpfull if you use the patch and want to use the CAN with canutils

https://community.freescale.com/docs/DOC-1437

[JamesAttewell]

Here is the packages.lkc file, I could only upload 3 files in the previous post

James

[JamesAttewell]

You need to use libsocketcan http://git.pengutronix.de/?p=tools/libsocketcan.git (get a snapshot from the top level of their GIT tree) and canutils http://www.pengutronix.de/software/socket-can/download/canutils/v4.0/canutils-4.0.6.tar.bz2. Both of these files should be placed under /opt/freescale/pkgs/

Attached are the new spec files for the above, they should live under ltib/dist/lfs-5.1/canutils and ltib/dist/lfs-5.1/libsocketcan.

Also attached is my updated pkg_map (lives under ltib/config/userspace). I would look at mine and just edit your existing one and add the following sections:-

config PKG_CANUTILS

config PKG_LIBSOCKETCAN

Finally, attached is my updated packages.lkc (also lives under ltib/config/userspace). Again I would look at mine and update yours to add the following:-

PKG_LIBSOCKETCAN                 = libsocketcan

PKG_CANUTILS                     = canutils

Once you have added all these bits to ltib, you can select the two new packages into your root filesystem and use them to configure the CAN ports...

Good luck...

James

Damon Gibson said:

Thanks for the quick response.  I was able to apply the patch and rebuild the kernel, but I see the new driver does not expose the same interface as the previous one.  For example, I had been using the sysfs interface to change the bitrate.  Apparently the new driver requires that the bitrate be initialized before doing:  ip link set can0 up, but I'm not sure how to do this.

Can you point me to where I can find documentation on how to interface with the new driver?

Thanks again,

Damon

[DamonGibson]

Thanks for the quick response.  I was able to apply the patch and rebuild the kernel, but I see the new driver does not expose the same interface as the previous one.  For example, I had been using the sysfs interface to change the bitrate.  Apparently the new driver requires that the bitrate be initialized before doing:  ip link set can0 up, but I'm not sure how to do this.

Can you point me to where I can find documentation on how to interface with the new driver?

Thanks again,

Damon

[JamesAttewell]

Hi Damon,

As far as I know the CAN is now working perfectly, I have not noticed any missing frames or anything. I have attached my patch file for all the changes I made, you should be able to figure it out from that. If I can be of any further help let me know...

Cheers

James

Damon Gibson said:

I have the same problem you found with the Freescale 2.6.35 kernel's FlexCAN driver.  In addition, I noticed that the driver does not always send all of the CAN packets.  For example, if I try to send 100 CAN packets quickly, only the first 36 packets get sent (but in the wrong order).  The remaining 64 CAN packets are apparently queued somewhere in the kernel.  If I then send another 100 packets, the remaining 64 packets from the first try get sent along with 36 packets from the second try (again in the wrong order).

Can you tell me if using the 2.6.38 driver would fix both problems?

When you ported the FlexCAN driver from 2.6.38 into 2.6.35, which files did you have to change?  If you could attach the changed files, I will try it with kernel 2.6.35 to see if it fixed both problems.

I agree with you that Freescale needs to fix this problem, either as a patch or as an SDK update.

Thanks.

James Attewell said:

I have managed to fix the problem with the CAN frame ordering. It is a bug in the FlexCAN driver. 

There are 64 hardware CAN frame buffers and the driver is using 32 of them round-robin for transmitting. These buffers seems to have a priority associated with them (lower buffers have higher priority) so if a multi-frame message causes the buffers to wrap from 31 back to zero, the frames at the end of the multi-frame message get sent before some of the previous frames.

My solution was to port the new mainline FlexCAN driver by Pengutronix from the 2.6.38 kernel into my 2.6.35 tree. This has solved the problem and everything is working fine now.

How do I submit a bug report to Freescale as this problem is going to exist on all their platforms that use the FlexCAN driver and it really needs to be fixed?

Cheers

James

[DamonGibson]

I have the same problem you found with the Freescale 2.6.35 kernel's FlexCAN driver.  In addition, I noticed that the driver does not always send all of the CAN packets.  For example, if I try to send 100 CAN packets quickly, only the first 36 packets get sent (but in the wrong order).  The remaining 64 CAN packets are apparently queued somewhere in the kernel.  If I then send another 100 packets, the remaining 64 packets from the first try get sent along with 36 packets from the second try (again in the wrong order).

Can you tell me if using the 2.6.38 driver would fix both problems?

When you ported the FlexCAN driver from 2.6.38 into 2.6.35, which files did you have to change?  If you could attach the changed files, I will try it with kernel 2.6.35 to see if it fixed both problems.

I agree with you that Freescale needs to fix this problem, either as a patch or as an SDK update.

Thanks.

James Attewell said:

I have managed to fix the problem with the CAN frame ordering. It is a bug in the FlexCAN driver. 

There are 64 hardware CAN frame buffers and the driver is using 32 of them round-robin for transmitting. These buffers seems to have a priority associated with them (lower buffers have higher priority) so if a multi-frame message causes the buffers to wrap from 31 back to zero, the frames at the end of the multi-frame message get sent before some of the previous frames.

My solution was to port the new mainline FlexCAN driver by Pengutronix from the 2.6.38 kernel into my 2.6.35 tree. This has solved the problem and everything is working fine now.

How do I submit a bug report to Freescale as this problem is going to exist on all their platforms that use the FlexCAN driver and it really needs to be fixed?

Cheers

James

[JamesAttewell]

Don't worry, I will be...

Keep up the good work on the i.MX support for the mainline kernel!

[RobertSchwebel]

Well, it safes you time in the long run. So you should try it :-)

rsc

[JamesAttewell]

ha ha, thanks for the input Robert. That is my plan but as you know there isn't always time to do these things when a bug needs fixing ASAP. Also its not such a straightforward thing to port all the changes from my Freescale 2.6.35 kernel to the latest mainline as it is quite different.

James

[RobertSchwebel]

We should talk you into using 3.2 or any other mainline kernel, instead of backporting the nice mainline driver to old kernels :-)

rsc

[JamesAttewell]

I have managed to fix the problem with the CAN frame ordering. It is a bug in the FlexCAN driver. 

There are 64 hardware CAN frame buffers and the driver is using 32 of them round-robin for transmitting. These buffers seems to have a priority associated with them (lower buffers have higher priority) so if a multi-frame message causes the buffers to wrap from 31 back to zero, the frames at the end of the multi-frame message get sent before some of the previous frames.

My solution was to port the new mainline FlexCAN driver by Pengutronix from the 2.6.38 kernel into my 2.6.35 tree. This has solved the problem and everything is working fine now.

How do I submit a bug report to Freescale as this problem is going to exist on all their platforms that use the FlexCAN driver and it really needs to be fixed?

Cheers

James