S32KのトピックRe: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd

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

XPW — Fri, 03 Jul 2026 08:57:37 GMT

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

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

danielmartynek — Fri, 03 Jul 2026 11:05:33 GMT

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

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

XPW — Wed, 08 Jul 2026 07:37:42 GMT

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

Clock_ip. c under RTD file

Power_ip. c under RTD file

Can initialize correctly。
However, when I activated it：

Clock_ip. c under RTD file

Power_ip. c under RTD file

Global variable initialization failed。

May I ask if there is a better solution?

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

danielmartynek — Thu, 09 Jul 2026 07:56:35 GMT

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

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

XPW — Tue, 14 Jul 2026 02:00:17 GMT

The link file has been modified for the following.

I have defined three global variables：

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

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

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

It doesn't seem to be aligned.

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

XPW — Thu, 16 Jul 2026 03:55:47 GMT

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

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

danielmartynek — Fri, 17 Jul 2026 13:04:08 GMT

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