Mark Roy

imx53 FlexCAN interface

Discussion created by Mark Roy on Feb 26, 2013
Latest reply on Nov 30, 2015 by TomE
Branched to a new discussion



I've been trying to get the FlexCAN modules to work correctly on an i.mx536 processor.    The board is a custom board similar to the QSB.     I have connected the CAN2 interface on its ALT2 muxing option (pins E5 and E6).  I have also double checked the iomuxing and it looks all correct.


I am using the 11.09 Linux BSP ( and have enabled the FlexCAN driver by adding/registering the platform data similar to how it is done in mx53_evk.c and mx53_ard.c for CAN2.  


I have also compiled/installled canutils (as described in All Boards FlexCAN )  and libsocketcan.   When I boot, everything looks good, and I can see the driver attributes in /sys/devices/platform/FlexCAN.1/ 


Continuing wth the All Boards FlexCAN instructions, I try and run "conconfig" but get "RTNETLINK answers; Operation not supported".   However, since it seems to be just configuring the bitrate,  I can set that myself  through the attributes interface above (ie   "echo 125000 > /sys/devices/platform/FlexCAN.1/bitrate" ) and it seems to work.


Then I bring up the interface:

ifconfig can1 up


Next I attempt to send a can message using cansend as per the instructions in the aforementioned post:

cansend can1 -i0x100 11 22 33 44


Issuing this command seems to "work", but I see no output on my can2 TX pin when I look at it with the oscilloscope.    Going back to the driver attributes, if I dump the transmit message buffers I see the message sitting in the buffer, but it doesnt look like it has been sent since the timestamp portion of the message buffer structure is not completed.   If I understand the reference manual, the timestamp should be automatically filled in when the message is sent.


$ cat dump_xmit_mb

mb[32]::CS:0xc040000 ID:0x4000000 DATA[1~2]:0x21,0x16



Also, looking at the message in the buffer, it seems the CODE field is 0b1100 with no RTR set which indicates "Transmit data frame unconditionally once" and it should automatically return to "inactive" 0b0000 after the message has been sent.  


It seems to me from looking at all of this that the asynchronous portion of the module is working correctly, allowing me to set/read registers, etc..  but for whatever reason, the synchronous portion is not working so the message buffer is not being processed and sent.


Dumping the registers for the module after trying to send a frame gives the following:

$ cat dump_reg












The only interesting thing to me at this point in these regs is the MCR, which when compared to the reference manual description of the register contains reasonable default settings.


From all of this, it leads me to believe that perhaps something is not right in the clocking of the module.     In the platform data I have listed:

.root_clk_id = "lp_apm" which was copied from one of the other boards configs.  This is the only configuration i have done for the clocking of the module.   I have not changed any of the settings pertaining to the CAN clocks in clock.c.    If I look at  /proc/cpu/clocks I can see lp_apm-0 listed with a rate of 24MHz and  both can1 and can2 clocks are listed also with a rate of 24MHz.


Any advice is appreciated.