i.MX28 CAN frame transmission order problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX28 CAN frame transmission order problem

7,848 Views
JamesAttewell
Contributor I

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

Labels (1)
0 Kudos
11 Replies

5,400 Views
samuelsalas
Contributor III

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

0 Kudos

5,400 Views
JamesAttewell
Contributor I

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

James

0 Kudos

5,400 Views
JamesAttewell
Contributor I

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

0 Kudos

5,400 Views
DamonGibson
Contributor III

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

0 Kudos

5,400 Views
JamesAttewell
Contributor I

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

0 Kudos

5,400 Views
DamonGibson
Contributor III

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

0 Kudos

5,400 Views
JamesAttewell
Contributor I

Don't worry, I will be...

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

0 Kudos

5,400 Views
RobertSchwebel
Contributor IV

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

rsc

0 Kudos

5,400 Views
JamesAttewell
Contributor I

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

0 Kudos

5,400 Views
RobertSchwebel
Contributor IV

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

rsc

0 Kudos

5,400 Views
JamesAttewell
Contributor I

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

0 Kudos