2396971_en-US

[#1]

S32G274 Wake-up abnormality

Hi NXP team,

Project background:

We have two S32G274 chips placed on the same board, referred to as chip1 and chip2. chip2 serves as a backup for chip1 — that is, when chip1 fails, chip2 takes over its functions.

Problem description:

Both S32G chips enter sleep state according to the command: the MCU enters Standby, and the PMIC enters Standby. They can be woken up via CAN or via KL15. During one particular test, we found that chip1 woke up normally and operated correctly, but chip2 did not work properly.

By measuring the PMIC voltages, we found that the PMIC output 3.3V, 1.8V, 1.1V and 5V, so the PMIC supply voltages were normal. However, there was no output on chip2's serial port, meaning it had not entered the A-core. At the time we suspected it was stuck in the bootloader stage.

We then measured the chip temperatures: chip1 was 50°C, while chip2 was 40°C. To determine where chip2 was getting stuck, we recovered chip2 by cutting the main power and powering it back on, and performed the following tests:

1. Halting chip2 with a while(1) loop when loading the A-core — the chip temperature was 45°C.
2. Halting chip2 with a while(1) loop before clock initialization — the chip temperature was 42°C.
3. Keeping chip2 permanently in reset state by continuously shorting the reset pin — the chip temperature was 40°C, which matches the temperature observed during the fault.

Problem summary:

We suspect that chip2's wake-up function is behaving abnormally, causing chip2 to remain stuck in a reset state. However, the exact root cause is still unclear.

Could you please help us analyze the possible causes and advise on how to further debug this issue?

Looking forward to your reply.

Best regards, Chenyin

Re: S32G274 Wake-up abnormalityHi Joey,

Thank you for your prompt response. Please find our answers to your questions below:

Question 1: The issue where Chip2 cannot be woken up is a very low-probability problem. We have been running for nearly a year and have only encountered this single case, so it is difficult to reproduce.

Question 2: Both Chip1 and Chip2 are woken up via CAN messages. The code logic for Chip1 and Chip2 is consistent, with possible differences only in the main logic execution and the failover handling part.

Question 3: The Standby entry process is as follows:

The M-core notifies the A-core via IPCF.
The A-core executes the shutdown procedure.
The A-core sends a command to the PMIC to enter Standby.
The M-core enters Standby mode.
Please let us know if you need any additional information or logs for further analysis.

Looking forward to your reply.

Best regardsRe: S32G274 Wake-up abnormality

Hi,Jerry_cao

Could you please provide more information?
1. The phenomenon that Chip 2 cannot be awakened only occurred in your work. Can it be reproduced?
2. Are both Chip 1 and Chip 2 awakened together through KL15?
3. What are your Standby and wake-up processes? Are both the M core and the A core involved? Does M core turn off A core first, and then M core enters Standby?

BR

Joey

Re: S32G274 Wake-up abnormality

Hi,Jerry_cao

Thank you for your reply and detail information.

1.Regarding the situation where Chip2 failed to wake up, Has the M core been awakened, and does the A core have any logs? did obtain any useful information on chip? 

2.Is failure within the normal operating range of the chip?
3. Is this only the one board that has this problem? Do other boards have this problem? The temperature test might not be sufficient for analyzing the problem. It suggests that you could try implementing an automated testing method to see if the issue can be reproduced again.

BR

Joey

Re: S32G274 Wake-up abnormalityHi Joey,

Thank you for your continued support.

After further investigation, we have identified the root cause: the issue is related to the external watchdog (GPT driver) feeding operation.

Current findings:

If the external watchdog is disabled at the very beginning of the code, the Standby entry and wake-up works correctly without any issues.

If the external watchdog is disabled only before entering Standby (while it runs normally during the main logic), the problem still reproduces.

This indicates that the watchdog feeding operation interferes with the Standby entry timing. Our current hypothesis is that the command sent to the PMIC to enter Standby may be disrupted by the watchdog feeding operation, causing a timing violation that prevents the device from entering Standby correctly.

Questions:

Could you please help analyze whether the watchdog feeding operation (GPT driver) could affect the timing of the PMIC Standby entry command?
Is there a specific sequence or timing requirement for the PMIC Standby entry command that we should follow?
Are there any known timing constraints between the watchdog peripheral and the PMIC standby entry sequence on the S32G platform?
Looking forward to your reply.

Best regards