The first 16K memory of S32K312 is filled by "DEADBEEF" after Sleep-Wakeup loops

[chenwilsoft]

The first 16K memory of the S32K312 chip will be filled with the pattern "DEADBEEF" after calling the `Mcu_SetMode` function to switch to the Run mode in the Sleep-Wakeup test loops. However, it occurs once or less after running the test for a whole day.

The test environment involves repeating the following sequence: Sleep -> delay 600mS -> Wakeup (switch to PLL) -> delay 600mS -> Sleep (switch to FIRC).

After calling `Mcu_SetMode`, if the issue occurs, the first 16K SRAM (starting from address 0x20400000) of the S32K312 chip is filled with the pattern 0xDEADBEEF, while the rest of the memory is filled with zeros. The flash memory works fine, and the initialization program runs as expected. However, after calling `Mcu_SetMode`, the first 16K SRAM is filled with the pattern 0xDEADBEEF.

There is no code to fill this pattern.

[chenwilsoft]

This is the default value, but not shown by the debugger. If I use code to compare the value in the specific memory, it can be true. It means that at that time, the value in the RAM is a special pattern. The problem seems to be caused by the current limit. It always occurs when I speed up the PLL to 120MHz. I'm trying to separate the process into 2 steps. Step 1 set PLL to 120MHz and give the clock to the core only. And step 2 give the clock to other peripherals. I'm still trying.

[danielmartynek]

Hi @chenwilsoft,

Regarding the clock, it is recommended to use one of the Clocking use case examples (RM, Section 24.7.2). 

In this case, it would be Table 148. Option B - Reduced Speed mode (CORE_CLK @ 120 MHz).

All the clocks must be set as per the table.

If one clock frequency is changed, we need to change all of them to keep the ratios between the clocks.

Best regards,

Daniel

[danielmartynek]

Hi @chenwilsoft,

This is likely just a default value showed by the debugger indicating that it is not able to read the actual memory.

Discussed here: https://github.com/zephyrproject-rtos/zephyr/discussions/50719

You should get better answer from SEGGER support.

Have you tried reading the memory with either the core or DMA and sent it out via any other interface?

Regards,

Daniel