/* We are going to use UART0 as flexcan1 */
&lpuart0 {
status = "disabled";
};
&flexcan1 {
status = "okay";
};
/* We are going to use UART2 as flexcan2 */
&lpuart2 {
status = "disabled";
};
/* Redefine the pins for flexcan2, as the default ones are used for the LVDS converter */
&pinctrl_flexcan2 {
fsl,pins = <
IMX8QXP_UART2_TX_ADMA_FLEXCAN1_TX 0x21 /* SODIMM 21 */
IMX8QXP_UART2_RX_ADMA_FLEXCAN1_RX 0x21 /* SODIMM 19 */
>;
};
&flexcan2 {
status = "okay";
};
Now flexcan1 becomes can0 and flexcan2 becomes can1 on Linux. can1 works as expected, but can0 won’t receive any data and when trying to send data it will fail with:
More information: I have also tried setting up a number of GPIOs as gpio-keys. All are working except the ones in SODIMM pins 36 and 38, aka UART_B_RXD and UART_B_TXD, which are associated to the FLEXCAN0 port. It’s like I can’t make any of the UART_B-related pins work as expected.
Well, pinctrl_lvds_converter defines a pin for SODIMM 55 (IMX8QXP_FLEXCAN1_TX_LSIO_GPIO1_IO18). I have redefined pinctrl_flexcan2 in order to avoid that collision, and FLEXCAN1 and the LVDS converter are working at the same time without any issues.
My problem is with FLEXCAN0 as defined in pinctrl_flexcan1 on imx8x-colibri-iris-v2.dtsi:
So except I am missing something those changes are unrelated. I tested them non the less, and of course it breaks the LVDS output (I still need the converter). Oh, the mcp2525 is present on the eval board, not the iris (or at least I can not find it in any iris dts).
Thanks @iagorubio and @dartd for your replies. I agree it can be an electrical issue between the Irisv2 board and the transceiver, but I have my doubts. I connected the other available CAN port in the SoM to the transceiver by using very small DuPont cables (far from ideal, I know) and it works. The very same thing against the first and official CAN port and it does not works.
In both cases the transceiver is connected to another transceiver connected to an RPi, and I can send and receive packets without issues.
The fact that I am also having issues setting other pins as GPIO-keys makes me think I might be missing something very important here or somehow I’ve got to screw the module :-/ (although I do not think so, but well, let’s not discard it).
I made a test here on my side using Colibri iMX8X and Evaluation Board. I couldn’t reproduce the issue you are seeing. After applying the overlay that I sent you here, everything worked using candump and cansend commands.
First of all: thanks a lot for taking the time to test. I am using a different board, the Iris V2, but this is still good. Also I do not see the dts, but we are using different boards after all.
Yes, I used 200000, even slower than what you used there.
Well, I have a board with two CAN transceivers.
can1 works on both CAN transceivers.
can0 does not works on either of them.
I can also make both CAN transceivers work with a Colibri iMX7D SoM of course different pin mapping).
With the iMX7D I tested both CAN ports against each other and again other board, individually.
With the iMX8DX I could only test successfully against the other board, of course.
Sure, I was just trying to check if it was something strictly related to the iMX8X, but apparently, it’s not. The overlay that I was referring to is this one: Can0: bus-off on iMX8DX - #3 by hfranco.tx. But I believe you’ve already tried it.
Thanks for confirming. There are some differences between iMX7D and iMX8X in this case, but I believe you already fixed that:
For Colibri iMX8X, the CAN interface that is located at pin 63/55 is compatible with the Colibri iMX6, the
Colibri iMX6ULL, the Colibri iMX7. Therefore, whenever only one CAN interface is required, it is
recommended to use the one available at pin 63/55. Additionally, the CAN interface on pin 34/32 is
compatible with the Colibri iMX6ULL, but not with the rest of the Colibri modules. Colibri iMX8X
modules use device tree enabled kernels with the drivers for FlexCAN built as a kernel module.
quick question about that, do you happen to have another Colibri iMX8X to test this issue?
Not me I’m afraid. Client has 3 more SoMs in which he tried the display issue and was going to try the GPIOs one, but can’t try the CAN stuff I’m afraid I’ll probaly be able to do so in some months… I think we should pause this thread until I get another SoM.
I’m sorry we couldn’t close this thread successfully (at least for now). There is nothing obvious that I can see from here.
Meanwhile, feel free to send any questions here and to contact our US sales if you need help with that. You can always send an email to support@toradex.com as well.