S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd

[XPW]

Sort out the logic and rewrite: As the title suggests, when I enabled eMCEM_1 in the app code, downloading the app using the official bootloader failed. If I didn't erase the chip, I couldn't enter the boot again, and even after powering it back on, it wouldn't solve the problem. I suspect that after powering it back on, the boot jumped to the app, but the app didn't run. When I disable eMCEM_1, this issue does not occur. How can I use boot to flash the app when eMCEM_1 is enabled

[danielmartynek]

Hi @XPW,

The problem description is not entirely clear.
If the application is being programmed through the bootloader, the eMCEM_1 configuration contained in the application should not affect the programming process itself, since the application is not executed during download, it is just a binary.
Only after the bootloader transfers execution to the application would eMCEM/FCCU-related configuration become relevant, and at that point, it would be useful to check:

• FCCU status registers
• DCM flags, MC_RGM flags.
• Or whether the application actually reaches main()

Based on the current description, it is unclear whether the programming operation fails, or whether programming succeeds and the issue occurs later when the application starts executing.

Could you clarify the exact sequence of events?

Regards,

Daniel

[XPW]

After my investigation, I found that some global variables were not initialized as defined when<eMCEM_1>was enabled。
Select a portion for explanation：
Firstly, when I haven't enabled the target

XPW_0-1783494597992.png
Clock_ip. c under RTD file

XPW_1-1783494731850.pngXPW_2-1783494792174.png

Power_ip. c under RTD file

XPW_3-1783494883662.png

XPW_4-1783494909192.png
Can initialize correctly。
However, when I activated it：

XPW_5-1783495188492.png

XPW_6-1783495223242.png
Clock_ip. c under RTD file

XPW_7-1783495794585.png

XPW_8-1783495823066.png

Power_ip. c under RTD file

XPW_9-1783495866324.png

XPW_10-1783495886502.png

Global variable initialization failed。

May I ask if there is a better solution?

[danielmartynek]

Hi @XPW,

Based on what I see in the screenshots, the variables are initialized correctly at first. However, after the eMCEM initialization, Clock_Ip_pfkNotificationsCallback contains an invalid pointer.
eMCEM does not magically change the pointer value. This looks much more like one of the following issues:

• Startup initialization (.data copy / .bss initialization) is not completed correctly.
• RAM corruption occurs before main().
• Linker sections overlap.
• Stack corruption.

Can you test it with the linker file from the SPD demo project?

BR, Daniel

[XPW]

What is the cause of this phenomenon and how should I investigate and solve it.

[XPW]

The link file has been modified for the following.

XPW_0-1783992772039.png

XPW_1-1783993101988.png

I have defined three global variables：

XPW_2-1783993317537.png

I found that when<eMCEM_1>is not enabled, after executing init_data-bss,

XPW_3-1783993342206.png

XPW_4-1783993406406.png

It seems to be aligned with 4 bytes and assigned correctly.

But when I enable<eMCEM_1>, after executing init_data-bss

XPW_5-1783994068084.png

XPW_6-1783994226472.png

It doesn't seem to be aligned.

[danielmartynek]

HI @XPW,

Based on the screenshots, I am not convinced there is actually a problem with the variable initialization itself. variable_a is an 8-bit variable, and enabling eMCEM will introduce additional variables, which can change the layout of the .data section. Therefore, seeing the variables at different offsets is expected and does not by itself indicate corruption.
I think the key question is whether the issue occurs when the application is run standalone, or only when it is programmed and started through the bootloader.
Can you reproduce the issue when programming the application directly with the debugger and running it without the bootloader? If the problem only occurs after loading the application through the bootloader, then the investigation should focus on the bootloader programming process, image layout, or bootloader handover rather than the application itself.

BR, Daniel