S32G274 Debugging CAN Communication After Dual-Core Boot-up

[sdx111]

I am currently debugging the CAN communication when both the M core and A core are started simultaneously. The CAN pins are PC_11 and PC_12. I need to apply FLEXCAN in the M7 core APP project, so I have disabled the settings of llce_can0 in the BSP35.0 of the A core's Linux (as shown in the figure). However, the phenomenon is that when the A core is in Uboot, the flexcan of the M7 core is communicating normally; but when the A core enters Linux, the flexcan of the M7 core stops working properly. Could you please tell me where else in the A core needs to be changed?

[alejandro_e]

Hello @sdx111,

Sorry for such the late update, I was out of the office for these past weeks. Are you still seeing the problem? If so, please let me know any update.

I noticed that you created a new post to continue the topic, if your problem was solve by my colleague please also let me know.

Thanks.

[sdx111]

It's still the same. The problem hasn't been solved.

[alejandro_e]

Hello @sdx111,

I understand, can you create a new post for this? due to the inactive time the tool we use to track the status of the posts has closed this one. You can create a new post explaining that it is a continuation of this topic and if you prefer you can tag me to continue working with me.

Thanks and sorry for the inconveniences 

[alejandro_e]

Hello @sdx111,

Please apply the following changes to remove the use of the LLCE can0 pins in Linux:

diff --git a/arch/arm64/boot/dts/freescale/s32g.dtsi b/arch/arm64/boot/dts/freescale/s32g.dtsi
index de9caffb3ca1..ff02f046676b 100644
--- a/arch/arm64/boot/dts/freescale/s32g.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32g.dtsi
@@ -379,18 +379,18 @@ llce_can_logger15: llce_can_logger15 {
 				status = "okay";
 			};
 
-			llce_can0: llce_can0 {
-				compatible = "nxp,s32g-llce-can";
-				mboxes = <&llce_mb S32G_LLCE_CAN_CONF_MB 0>,
-					 <&llce_mb S32G_LLCE_CAN_RX_MB 0>,
-					 <&llce_mb S32G_LLCE_CAN_TX_MB 0>;
-				mbox-names = "config", "rx", "tx";
-				clocks = <&clks S32G_SCMI_CLK_LLCE_CAN_PE>;
-				clock-names = "can_pe";
-				pinctrl-names = "default";
-				pinctrl-0 = <&llce_can0_pins>;
-				status = "disabled";
-			};
+//			llce_can0: llce_can0 {
+//				compatible = "nxp,s32g-llce-can";
+//				mboxes = <&llce_mb S32G_LLCE_CAN_CONF_MB 0>,
+//					 <&llce_mb S32G_LLCE_CAN_RX_MB 0>,
+//					 <&llce_mb S32G_LLCE_CAN_TX_MB 0>;
+//				mbox-names = "config", "rx", "tx";
+//				clocks = <&clks S32G_SCMI_CLK_LLCE_CAN_PE>;
+//				clock-names = "can_pe";
+//				pinctrl-names = "default";
+//				pinctrl-0 = <&llce_can0_pins>;
+//				status = "disabled";
+//			};
 
 			llce_can1: llce_can1 {
 				compatible = "nxp,s32g-llce-can";
@@ -615,23 +615,23 @@ usbotg: usb@44064000 {
 };
 
 &pinctrl {
-	llce_can0_pins: llce_can0_pins {
-		llce_can0_grp0 {
-			pinmux = <S32CC_PINMUX(43, FUNC0)>;
-			input-enable;
-			slew-rate = <S32CC_SLEW_208MHZ>;
-		};
-
-		llce_can0_grp1 {
-			pinmux = <S32CC_PINMUX(44, FUNC2)>;
-			output-enable;
-			slew-rate = <S32CC_SLEW_208MHZ>;
-		};
-
-		llce_can0_grp2 {
-			pinmux = <S32CC_PINMUX(745, FUNC2)>;
-		};
-	};
+//	llce_can0_pins: llce_can0_pins {
+//		llce_can0_grp0 {
+//			pinmux = <S32CC_PINMUX(43, FUNC0)>;
+//			input-enable;
+//			slew-rate = <S32CC_SLEW_208MHZ>;
+//		};
+//
+//		llce_can0_grp1 {
+//			pinmux = <S32CC_PINMUX(44, FUNC2)>;
+//			output-enable;
+//			slew-rate = <S32CC_SLEW_208MHZ>;
+//		};
+//
+//		llce_can0_grp2 {
+//			pinmux = <S32CC_PINMUX(745, FUNC2)>;
+//		};
+//	};
 
 	llce_can1_pins: llce_can1_pins {
 		llce_can1_grp0 {
diff --git a/arch/arm64/boot/dts/freescale/s32g274a-bluebox3.dts b/arch/arm64/boot/dts/freescale/s32g274a-bluebox3.dts
index 0247b542f98b..fe93303e8ca9 100644
--- a/arch/arm64/boot/dts/freescale/s32g274a-bluebox3.dts
+++ b/arch/arm64/boot/dts/freescale/s32g274a-bluebox3.dts
@@ -91,9 +91,9 @@ &llce_boot_status {
 	status = "okay";
 };
 
-&llce_can0 {
-	status = "okay";
-};
+//&llce_can0 {
+//	status = "okay";
+//};
 
 &llce_can1 {
 	status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi b/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
index afe8a5cea3e1..ada20f67f2d7 100644
--- a/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
@@ -168,9 +168,9 @@ &llce_boot_status {
 	status = "okay";
 };
 
-&llce_can0 {
-	status = "okay";
-};
+//&llce_can0 {
+//	status = "okay";
+//};
 
 &llce_can1 {
 	status = "okay";

After that, if you list the llce can0 nodes and pins like below, you should not be able to see llce_can0:

root@s32g274ardb2:~# ls /sys/firmware/devicetree/base/soc/siul2@4009c000/siul2-pinctrl@4009c240/llce_can0_pins
ls: cannot access '/sys/firmware/devicetree/base/soc/siul2@4009c000/siul2-pinctrl@4009c240/llce_can0_pins': No such file or directory
root@s32g274ardb2:~# ls /sys/firmware/devicetree/base/soc/llce@43a00000/llce_can0/
ls: cannot access '/sys/firmware/devicetree/base/soc/llce@43a00000/llce_can0/': No such file or directory

In contrast, when having those nodes, listing as above shows the device tree subnodes.

Let me know if you are able to use the CAN0 in the M7 after that change.

[sdx111]

I have made the changes as per the above instructions. However, after the A core enters the Linux system, the CAN0 communication of the M core is still abnormal.


s32g274ardb2 login: root
root@s32g274ardb2:~# ls /sys/firmware/devicetree/base/soc/siul2@4009c000/siul2-pinctrl@4009c240/llce_can0_pins
ls: cannot access '/sys/firmware/devicetree/base/soc/siul2@4009c000/siul2-pinctrl@4009c240/llce_can0_pins': No such file or directory
root@s32g274ardb2:~# ls /sys/firmware/devicetree/base/soc/llce@43a00000/llce_can0/
ls: cannot access '/sys/firmware/devicetree/base/soc/llce@43a00000/llce_can0/': No such file or directory

[alejandro_e]

Hello @sdx111,

I see, let me test some configuration and I will get back to you.

Thanks 

[sdx111]

After I removed the initialization codes for both can0 of A's BSP35.0 and llcecan0, when the M core was not loading the PFE, the can0 of M core was able to communicate normally. However, if I added "DISTRO_FEATURES_append += 'pfe'" and "NXP_FIRMWARE_LOCAL_DIR = '/home/hhkj/linux3/fsl-auto-yocto-bsp35.0/firmware_bin/'" in /fsl-auto-yocto-bsp35.0/build_s32g274ardb2/conf/local.conf, meaning that after the PFE was loaded in the A core, the M core seemed to have crashed. Since I need to apply PFEMAC0 and pfemca1 in the M core using CAN0 and SGMII mode, and in the A core using RGMII mode for PFEMAC2, I want to know why the loading of PFE's firmware in the M core would affect the CAN0 communication of the A core when only CAN0 communication is running in the M core?

[alejandro_e]

Hello @sdx111,

I have not seen any behavior like the one you mention, being that the PFE and CAN are interfering with each other. However, I did some change that might solve your issue, in pinctrl-s32g.c#L430 I removed the lines with the problematic pins, in your case it should be the following two:

S32CC_PINCTRL_PIN(S32G_MSCR_PC_11),
S32CC_PINCTRL_PIN(S32G_MSCR_PC_12),

I did this tests with the pins that correspond to the RGB led in the RDB2, when removing the respective pins from the list, the pins stay "floating" and you can see the leds slightly ON, instead of turning off like they normally do once Linux boots.

Can you do that test and let me know if now the CAN0 pins work correctly in the M7 core?

Thanks

[sdx111]

I have made the necessary changes to the pinctrl-s32g.c file as per your instructions. However, the issue still persists. Whenever I load the PFE firmware (see the attached image), after the A core enters the Linux system, the CAN0 of the M7 core becomes abnormal. If I do not load the PFE firmware, after the A core enters the Linux system, the CAN0 of the M7 core functions normally. Where should I look for the problem? Or could you please test for me after loading the PFE firmware?

 

   

[alejandro_e]

I investigated internally and did not find any restriction when using LLCE and PFE. Can you check if the following registers change before and after Linux boots?

Thanks