S32KのトピックRe: S32K3 Standby RAM data modified before Reset_Handler

S32K3 Standby RAM data modified before Reset_Handler

Jason07 — Thu, 20 Aug 2026 03:35:14 GMT

Hello,

When I debug S32K344 with PE Micro, I found that an array(__attribute__ ((section(".standby_data"))) volatile uint32_t WkupSourcestatus1[64];) located in the standby RAM section is unexpectedly modified when entering main(). Then, as shown in the attached video, I manually modified the registers to reinitialize the standby RAM area. The data was correctly initialized to 0, and after entering main(), everything ran fine. However, after a reset, when I enter the Reset_Handler, the data in the WkupSourcestatus1 array is modified again. Why is this happening? I noticed that a large number of 0x5AA55AA5 values appear in the array. Is this related to the SBAF_BOOT_MARKER? I tested this on another board and the phenomenon is the same.

Then I switched to using J-Link for debugging and found that no abnormality occurs during a reset while debugging. However, after a debug session is restarted, all data in the standby RAM area becomes 0xDEADBEEF. Is this expected behavior?

S32K344

S32DS3.6.4

RTD700

PE v.6.0.8

BR,

Jason

Re: S32K3 Standby RAM data modified before Reset_Handler

Robin_Shen — Mon, 24 Aug 2026 07:41:10 GMT

Sorry for the late reply; I've had a lot of inquiries to handle lately.

I suggest you refer to the discussion on S32K311 standby RAM retention for how to use standby RAM.

Best Regards,
Robin

Re: S32K3 Standby RAM data modified before Reset_Handler

db16122 — Tue, 25 Aug 2026 08:45:05 GMT

The standby RAM content will remain during reset and the value you observed should be the content before MCU reset

=======================================================================================

The RAM is integrated by the SRAM memory and the TCM. Part of the SRAM memory is available in standby
mode. This means that the content of this memory are retained after setting the MCU in standby mode. The
S32K3 product family leverages the TCM feature of ARM Cortex M7 architecture, whose main purpose is to
provide a deterministic access time to the cores to some important data avoiding any delay in the access. This
feature can be exploited in Real Time Operating Systems.

As noted, the data stored in the Standby SRAM memory sourced by Standby domain is retained when
the MCU is in standby mode and available after the wakeup. But the data in SRAM sourced by Run
domain is not available and it needs to be initialized after the wakeup to avoid ECC errors. Is important
to remark that after wakeup, the Standby SRAM doesn't need to be initialized to avoid ECC error, but
the rest of the SRAM does need it, so a proper distinction should be performed in the Startup code. An
example to make this distinction is depicted in the following code.

Re: S32K3 Standby RAM data modified before Reset_Handler

Jason07 — Wed, 16 Sep 2026 03:28:27 GMT

Hi

Sorry for the late reply.

In my test, I did not perform any sleep/wake-up operation. I only performed a reset through S32DS, and this caused the data in the standby RAM area to change. Checking the map file, the variable is indeed located in standby RAM (0x20400000). I checked the link you provided, and it seems to be unrelated to the issue in that link.

BR,
Jason

Re: S32K3 Standby RAM data modified before Reset_Handler

Robin_Shen — Fri, 18 Sep 2026 04:12:37 GMT

Hi Jason,

J-Link: 0xDEADBEEF — ECC initialization from JLinkScript

This is expected behavior, performed by the `SetupTarget()` function built into J-Link's `S32K344.jlinkscript`. Please check for log entries similar to the following:

SetupTarget() start Initializing ECC RAM... RAMCodeAddr: 0x20000000 RAMInitAddr: 0x20000010 RAMInitSize: 0x00007FF0 InitPattern: 0xDEADBEEF ECC RAM initialized successfully Initializing ECC RAM... RAMCodeAddr: 0x20000000 RAMInitAddr: 0x20400000 RAMInitSize: 0x00004000 InitPattern: 0xDEADBEEF ECC RAM initialized successfully ← Standby RAM! SetupTarget() end - Took 25.3ms

I am not sure if PEMicro has a similar mechanism, but the console log below:

;begin_cs device=$00400000, length=$003F4000, ram=$20400000 Loading programming algorithm ...

It appears that the flash programming algorithm is temporarily loaded into RAM at address $20400000 (the starting address of the Standby RAM) for execution.

You may need to verify this further with PEMicro technical support. Do you have a PEMicro account, or would you like me to check with them?

Re: S32K3 Standby RAM data modified before Reset_Handler

Jason07 — Fri, 18 Sep 2026 05:24:30 GMT

Hi,

I don't have a PEMicro account. If possible, please help me check with PEMicro technical support. Thank you very much.

BR,
Jason

Re: S32K3 Standby RAM data modified before Reset_Handler

Robin_Shen — Mon, 21 Sep 2026 02:49:10 GMT

Hi Jason,

I received a reply from a PEMicro technical support engineer:
PEmicro uses RAM at address 0x20400000 to perform flash programming operations.

Best Regards,
Robin