Hi I have been working with getting CAN up and working on our IMX8QXP 2GB IT we have built our own development adapter and I currently have 1/3 CAN up and running but I need them all to function. We have triple and quadruple checked the wiring on our add-on board and it should be correct but I’m linking the schematics just in case.
Can1 pin 34, 35 “Linux CAN0? named Can1 in datasheet but CAN 1 in pintool”
Gives no errors in my CAN validation tool but no traffic passes.
Can2 pin 38, 39 "Linux CAN1? named Can0 in datasheet but CAN 2 in pintool
Gives errors on the CAN bus.
Can3 pin 26, 27 "Linux CAN2? named Can2 in datasheet but CAN 3 in pintool "
Works flawlessly.
ifconfig gives the following information.
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 -00
UP RUNNING NOARP MTU:72 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:2 overruns:0 carrier:2
collisions:0 txqueuelen:1000
RX bytes:32 (32.0 B) TX bytes:8 (8.0 B)
Interrupt:38
can1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 -00
UP NOARP MTU:16 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:24 (24.0 B) TX bytes:0 (0.0 B)
Interrupt:39
can2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 -00
UP RUNNING NOARP MTU:16 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:224 (224.0 B) TX bytes:13 (13.0 B)
Interrupt:40
I have linked our revised fsl-imx8qxp-colibri-eval-v3.dtsi we have done a kernel patch with the change and everything shows up in linux correctly as can be seen in the ifconfig.
I have disabled SPI / UART-A / UART-B / UART-C in order to not have any conflicts.
But I’ve discovered that only FlexCAN2 is in the datasheet 33/35 are both ALT0 and set to that as default.
While FlexCan1 *datasheet 19/21 are set to ALT2 while the default is set to ALT0/4.
Same thing on FlexCAN0 *datasheet 34/32 are set to ALT0 while the default is set to ALT4/0
Do i need to disable all other functions using the pins or are there some way to change the pins default function?
I would appreciate an example on how to disable the other functions if need be or how to set the pin default correctly.
As for conflicting interfaces flexcan1 conflicts with UARTB and flexcan3 conflicts with UARTA. Flexcan2 doesn’t conflict with anything as far as I can tell. Other than that you’re adapter board doesn’t seem to complex so I doubt there’s any issues there as long as the wiring is correct.
So let’s try looking at your process. What I mean is what are you doing to enable, configure, and verify the CAN interfaces? Did you follow the steps as in this document: How to Use CAN on TorizonCore | Toradex Developer Center
Or did you do something different? Please give detailed steps in case we need to attempt to reproduce this on our side.
Ah okay you’re using our 4.0 Torizon then. Hmm we never did much testing/validation with this module and CAN on 4.0 Torizon. Just as a sanity check could you perform a quick test with your setup on 5.0 Torizon and see if there’s any differences?
I need some time to see whether the differences between 4.0 and 5.0 would even make a difference here.
It’s highly recommended to work with 5.X since that is the version the first production release of Torizon will be based off of. Also the screen output is a known issue since parallel RGB is off by default in 5.0 but can be re-enabled. Though we are going to re-enable it soon in the future. What are the other issues 5.X that don’t work for you?
I did a quick test myself on 5.X and strangely enough can1 works for me but can0 and can2 don’t. On my side I was able to set the bitrate for all 3 CAN interfaces and also enable them with ip link. But, once I sent a message with cansend, I get a similar bus-off message on can0/2. Is this similar to what you’re observing on your end as well?
I’m still investigating to see if this was some kind of user mis-configuration or perhaps a genuine bug.
Alright was worried that I would have to change the pins by myself so that’s a great relief.
I’ll ask an additional question before I go into the other stuff is the FLEXCAN name in the datasheet the same as the ones represented in ifconfig? It’s a bit confusing when the pintool and driver is based at 1 but not the datasheet ^^
My process is very close to yours I’m not deploying the tools in a container but instead i provide them as a part of my Yocto build which is based upon your latest 4.x.x Zeus@TorizonCore revision. Then I set up everything in the same way but with a bash script.
This is my core recipe:
We are using 250kbit/s instead of 500 but that’s the only difference that i can find.
ip link set can0 type can bitrate 250000
I’ll be using the “pin tool naming for the can devices bellow”
I have tried using using the can tools and they work flawlessly on can3 I have an external usb can-debugger that I’m able to both send and receive data with so i can verify that cansend and candump is working correctly. That device is giving an error when connecting can2 that’s why I thought there might be something conflicting on the pin like gpio. The can1 device gives no error on my usb debugger but no data enters or leaves.
I’ll add that there are many other things that do not work currently work when i use 5.x.x @ Torizon like no screen output and many other small things so I would like to focus on getting all can buses up and running on version 4.x.x
Firstly it’s a matter of time/cost we have everything except the final CAN buses working on Torizon version 4. When converting to version 5 both our current kiosk and the weston container stops working along with currently no display output which makes it hard to test and validate. It makes version 4 seem more stable currently and i have to motivate additional time spent on this part of the project.
Yes that is my observation as well setting bitrate works buses seems to be online/working. But once you try to send data over them with example cansend it changes state to bus-off but for me it only affects CAN1 with torizon 5 on IMX8X revision B and on torizon 4 it affected CAN 0 & 1
