LLCE on M7 stop unexpectly while A53 start u-boot

[ShenYi]

Hi,

I use can_mcal_can2can example and run on M7, it can run normally only on M7_0.

But when I tried to boot M7 and A53 at the same time, I met a problem that M7 would stop work while A53 started u-boot.

Info:

1. The board is S32G274ARDB2. LLCE version: 1.0.4. RTD version: 3.0.2 HF01. Platform Software Integration: 2022_06. BSP version: 34.

2. I refer to S32G_Bootloader_V2-2022.1024_eng.pdf to configure bootloader.

3. As UART demo, I disable “Mcu Init Clock API” and “Port” in “Sample_App_LLCE_CAN2CAN” project, also modified app’s code:

4. Configure clock for MCU configuration of M7 app and bootloader.

Bootloader_S32G2XX_ASR_4.4_M7:

Sample_App_LLCE_CAN2CAN:

5. Modify sample_app_llce\llce_sample_app_af\platform_common\build_files\src\gcc\sample_app_linker_file.ld. Change the region of int_sram to 0x34400000.

The problem: M7 stopped work while A53 start u-boot.

Question: Any other conflict between M7 and bootloader except port/clock/interrupt?

Thanks.

[Daniel-Aguirre]

Hi,

Have you modified anything under the dts files? We understand that all LLCE pins are also enabled under Linux, which may cause a resource conflict.

Also, how do you know that the M7 stopped working? Does the A53 can continue no problem?

Please, let us know.

[ShenYi]

Hi,

    Thanks for your reply.

    I didn't modify anything under the dts files before. And I modified Can_Driver_Sample_Test to make CONTROLLER1 keep sending messages all the time. But when UART0 printing messages below, CONTROLLER1 stopped sending messages while A53 can continue no problem.

NOTICE: BL2: v2.5(release):bsp33.0-2.5-dirty
NOTICE: BL2: Built : 21:48:25, Mar 24 2023
NOTICE: BL2: Booting BL31

U-Boot 2020.04 (Mar 23 2023 - 18:15:43 -0700)

   This time I tried to modify dts file to resolve this problem, but I failed.
    First, I modified status of "&llce_can0" to "&llce_can15" from "okay" to "disabled" in ~/linux/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi. Then remake to generate new dtb file into SD-Card.
    Secondly, I modified status of "&llce_dte_sram" to "&llce_boot_status" from "okay" to "disabled" too.
    Finally, I modified "s32g.dtsi" which has config "llce_canX_pins".
    However, the problem still exists.

    So, are my these changes correct? And I have met the problem before A53 "Load and exeDTB & Kernel" accordint to AN13750.pdf, is it possible that m7 app and fip.bin conflict?

Thanks.

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

Could be a problem of LLCE FW being loaded 2 times, have you eliminated the LLCE loading from Linux? The following thread may provide insight on this:

Re: How to make LLCE_CAN work on M7 for multiboot ... - NXP Community

Also, can you confirm if loading a simple blink provides the same outcome? To discard the modifications to the linker.

Please, let us know.

[ShenYi]

Hi,

    I didn't enable LLCE CAN or specify the location where firmware binaries on A53. So it's unlikely to be the problem of LLCE FW being loaded 2 times.

    And I have already completed the UART example (M7 + A53) successfully refer to S32G_Bootloader_V2-2022.1024_eng.pdf before. Same to LLCE example, I modifyied the link file in which the region of int_sram changed from 0x34000000 to 0x34400000.

    However, I still think maybe there is conflict between M7 app and fip.bin. Because S32G is at Booting BL31 or U-Boot when M7 stopped sending CAN messages, which time Linux hasn't boot yet.

    But I have no idea what conflict it is, could you give me a little guidance?

Thanks.

[Daniel-Aguirre]

Hi,

When you say "I didn't enable LLCE CAN or specify the location where firmware binaries on A53", we understand that you are not using the pre-built BSP by NXP, is this correct?

As for additional guidance, we can recommend also looking into AN13750 which details an application with M7_0 + M7_1 + M7_2 + A53. The linker being used under the M7 application is different than the one being explained under the "S32G_Bootloader_V2-2022.1024_eng.pdf" file.

You could verify if the steps you are following are similar to the ones explained under AN13750 and verify if using the M7 app linker could provide any difference.

Please, let us know.

[ShenYi · Accepted solution]

Hi,

    Thank you for your reply. I have found the reason that CAN_PE_CLK conflict between ATF and M7 which caused baudrate of LLCE_CAN been changed not as expected.

Thanks.