CAN Bus not working on M4 when booting Linux

Technical Support
, , , ,
1

Hello

Running the application on the M4 core without booting Linux works well. If Linux is booted as well then the CAN Bus does not work anymore. Packages cannot be sent. What could be the issue? We already disabled a few things in out linux device tree - but maybe more has to be disabled?

We disabled the following things:

&ecspi3 {
status = “disabled”;
};

&gpt1 {
status = “disabled”;
};

&uart2 {
status = “disabled”;
};

Which devices have to be disabled as well for it to work? Is there an overview somewhere that tells which devices need to be disabled in the tree when using CAN bus, …? That would be a big help.

Best

Beni

2

Which pins are you using for CAN? Which BSP version are you using?

3

It is probably either clocking or pinmux. Assuming you are using SODIMM 55/63 make sure you remove the two pinmux configuration from pinctrl_hog_1:

--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -289,8 +289,6 @@
                pinctrl_hog_1: hoggrp-1 {
                        fsl,pins = <
                                MX7D_PAD_UART3_RTS_B__GPIO4_IO6         0x14 /* SODIMM 131 USBH OC */
-                               MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3     0x74 /* SODIMM 55 */
-                               MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2     0x74 /* SODIMM 63 */
                                MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16       0X14 /* SODIMM 77 */
                                MX7D_PAD_EPDC_DATA09__GPIO2_IO9         0x14 /* SODIMM 89 */
                                MX7D_PAD_EPDC_DATA08__GPIO2_IO8         0x74 /* SODIMM 91 */
4

We use default pins for CAN2 on the colibri evaluation board (SODIMM 178/188)

5

I tried to do this, but with the SODIMM 178/188 pins. Issue was that after the device tree update ssh was extremely slow and scp didn’t work properly anymore. Tried to rollback to the old image, but there is still some strange behavior.

Strange behavior includes

  • 1 board that seems had the kernel overwritten (Bad Linux ARM zImage magic! at bootup), despite only writing to ubi0_2 with ubiupdatevol. Can it be that the evaluation board messes up the ubi partition numbering?
  • I don’t get any output on UART_B if UART_A is connected on the evaluation board
  • I can’t get the toradex easy installer working sometimes. I tried unplugging as much unnecessary peripherals (only USB to X29, Monitor to X24 and power) as possible, but still no luck
6

Short update regarding the toradex easy installer issue. It worked now, had still the UART_B attached.

7

The ssh / scp issues don’t appear anymore (Re enabled foolishly &ecspi3 { status = “disabled”; }; because I thought it was unnecessary). Means we have now an image with the pinmux disabled, but it doesn’t yet seem to work

8

Which BSP version are you using?

9

I assume you enabled &flexcan2 and removed pinctrl_hog_4 to free SODIMM 178/188?

To isolate which change really affects operation I recommend adding in change by change, e.g.

  1. Just remove pinctrl_hog_4, see whether any side effect appear (without M4 firmware!).
  2. Start M4 firmware with removed pinctrl_hog_4 and see whether that makes a difference
  3. Adding in other changes…

If this does not help, can you share the complete changes you did to the device tree now and the output of dmesg?

10

I didn’t enable flexcan2, just disabled pinctrl_gpio4. Turned out that was the solution. Thanks a lot.

As for the encountered issues. The one where the kernel was overwritten resulted from a ubi part ubi command. I tried to load an .elf file from micro SD, because I thought the writing of the executable doesn’t work. Maybe make a note in the FreeRTOS tutorial (FreeRTOS on the Cortex-M4 of a Colibri iMX7 | Toradex Developer Center). For not overwriting the linux kernel this should help run setup; setenv bootargs ${defargs} ${ubiargs} ${setupargs} ${vidargs};. I didn’t test it, but I did run multiple times run setup; setenv bootargs ${defargs} ${ubiargs} ${setupargs} ${vidargs}; ubi part ubi && run m4boot to just run the M4 executable without booting linux. Works like a charm, but one should reset manually afterwards.

As for the issue with the UART_A / UART_B. It seems that they get disconnected kind of randomly sometimes. If it happens removing and reconnecting the adapter is the only thing that works. Did someone else encounter the issue? That was the reason I assumed the firmware deploying doesn’t work anymore…

Ah yes, the final issue on our side was probably a defective board -.- switched carrier board and it worked

11

Thanks for the update! Glad everything worked out.

I noticed that using ubi part ubi multiple times leads to problems at times. I will add a note.

UART_A/UART_B: What adapters are you using? On my desk there is USB hub where I have multiple connected of those, it happend to me in the past when I attached something “not according to spec” that the whole USB hub reset and hence all open USB to RS232 sessions got disconnected. Maybe something similar?

12

Hm, for me it erased the kernel already the first time I used ubi part ubi if I didn’t call the setup functions first. Maybe it’s related to our changes, because I think I used it with the default image without any issues.

Yes, that could be the cause. I think the prolific adapters could go under “not according to spec”.

13

thanks for the information.
best regards, Jaski