topic Re: S32K394: Clarification on STCU2 self-test and system RAM retention across functional reset in S32K

S32K394: Clarification on STCU2 self-test and system RAM retention across functional reset

SBalaji — Wed, 06 May 2026 05:21:42 GMT

Hello,

With reference to “S32K344 STCU BIST quest - NXP Community” on the NXP Community, I would like to request clarification regarding the interaction between STCU2 self-test and system RAM retention across functional reset on S32K394.

In Chapter 29.8, “System RAM retention across functional reset”, the Reference Manual S32K396RM Rev. 4, 11/2024 states that:

system RAM retains content during functional reset
retention is ensured through the crossbar halt handshake
this applies to system RAMs only
this does not apply to HSE_B or peripheral memories

Based on this description, my understanding is that system SRAM contents should remain valid across a functional reset.

However, in the context of STCU2 self-test, it appears that SRAM contents may no longer be preserved, even though the resulting reset is treated as a functional reset.

Therefore, I would appreciate confirmation of the following interpretation:

the functional reset itself still preserves system RAM
but the STCU2 self-test operation may already modify or overwrite or invalidate SRAM contents before that reset occurs

Could you please confirm whether this interpretation is correct for S32K394?

Thank you.

@danielmartynek

Re: S32K394: Clarification on STCU2 self-test and system RAM retention across functional reset

danielmartynek — Wed, 06 May 2026 12:52:56 GMT

Hi @SBalaji,

1. Yes, the SRAM content is preserved across functional resets.

2. Yes, this is the problem as the MBIST is executed over the entire SRAM, which overwrites its contents.

The SPD/SAF BIST driver supports only two configurations, both of which execute MBIST across the entire SRAM.

Regards,

Daniel

Re: S32K394: Clarification on STCU2 self-test and system RAM retention across functional reset

SBalaji — Thu, 07 May 2026 03:58:33 GMT

@danielmartynek

Many thanks for your response.

Our project uses the Standby SRAM region to exchange information between three different software images: Boot Manager, Bootloader, and Application.

Only after a Power-on Reset / Destructive Reset, the Boot Manager initialize this Standby SRAM region.

After a functional reset, this memory region is intentionally left untouched so that it can retain useful information for the other software images.

The current issue for us is that after BIST self-test, the SRAM contents appear to be invalidated, even though the resulting reset is a functional reset.

As a result, when the Boot Manager later reads a value from Standby SRAM, it triggers an exception.

Our assumption, based on Section 29.2.2 "Chip reset types" in S32K396RM Rev. 4, 11/2024, is that loss of SRAM contents should be associated with destructive reset, not functional reset.

Therefore, we would like to understand the following:

Is there a specific reason why BIST self-test results in a functional reset, even though it appears to cause SRAM re-initialization or loss of SRAM validity?
Could you also please confirm whether this behavior is expected by design on S32K394?

This distinction is important for our software architecture, because we currently rely on Standby SRAM retention across functional resets for communication between Boot Manager, Bootloader, and Application.

Thank you.

Re: S32K394: Clarification on STCU2 self-test and system RAM retention across functional reset

danielmartynek — Thu, 07 May 2026 07:13:42 GMT

Hi @SBalaji,

The SRAM content is retained across all functional resets, including the ST_DONE STCU2 reset.
However, the BIST driver triggers an MBIST operation on the entire SRAM before the functional reset. Since the MBIST is destructive, it overwrites the SRAM contents.
As a result, although the reset itself does not clear the SRAM, the data are effectively lost due to the preceding MBIST execution. Therefore, reinitialization of the SRAM is required.
This behavior is expected.

Regards,

Daniel