S32K312 Pad-Level during wakeup

[Simon_Liu]

Hi

When I used the K312 chip to test the Wakeup function, I found that the GPIO output by OutPut can maintain a high level output after entering standby, but it will become a low level after wakeup.
Here is my setup:
1. Use the DS tool to select [Global Padkeeping Enable] under StandByMode in the Power component, and set the [Pad keep enable] option of the GPIO used in the pin component to Enable.
2. In the case of setting the above PadKeeping, initialize GPIO in Main and set high level output
3. Call the function Power_Ip_SetMode to enter StandBy

How can I keep the high level of the output terminal during wakeup?

[Senlent]

Hi@Simon_Liu

The test of PakKeeping in the figure below is very easy to understand.

Senlent_0-1686192414352.png

[Simon_Liu]

Hi @Senlent 

I use DS configured as follows:
1. In the pin tool, configure PTE18 as Pad keep enable, which corresponds to PKE in SIUL2_MSRC, and set it during PortInit

Simon_Liu_2-1686195291503.jpeg

2. In the Power component, select Global Padkeeping Enable, which corresponds to STANDBY_IO_CONFIG in DCMRWF1, which is set by calling the function Power_Ip_SetMode when entering StandBy

Simon_Liu_1-1686195286451.jpeg

The process in the Main function is as shown in the picture below, but after wakeup, PTE18 will still be pulled down

Simon_Liu_3-1686195322330.pngSimon_Liu_4-1686195421724.png

[Senlent · Accepted solution]

Hi@Simon_Liu

I don't think this is a problem.

This picture is not very clear and I have highlighted the important place for your obervation, as you can see, the level here is also pulled down.

Senlent_0-1686207845152.png

the reason it say in picture conclusion.

"When waking up from standby mode, HSE non-secure boot will cost 1.8ms,the startup code(from reset_handler to main) will cost 4.3ms, Clock_Ip_Init will cost 830ms(Optimization level -O0). When enabling padkeeping, you can make sure the IO voltage will retain the setting in run mode during these 3 periods of time, until you disable the padkeeping and reset the port after waking up."

After your program enters the main function, it initializes the PORT after a delay, and then pulls it high

[Simon_Liu]

Hi @Senlent 

Thank you for your answer, I still have one thing I don't understand: what is the action after wakeup or the pad level is pulled down due to the function I called? Is it caused by writing 1 to the STANDBY_IO_CONFIG bit in the register DCMRWF1? Can this drop be avoided?

[Senlent]

Hi@Simon_Liu

I can't think of a better way to solve your application requirements.

If you want it to be always in a high state, why not directly use an external circuit to pull up

[Simon_Liu]

Hi @Senlent 

Based on your answer above, I understand that after wakeup, the port will be reset only when the STANDBY_IO_CONFIG bit 1 in DCMRWF1 is set. So if the port is initialized and set to a high level before setting DCMRWF1, will this high level be maintained?
I did this test and found that this solution can keep the port high.

[Senlent]

Hi@Simon_Liu

1.So if the port is initialized and set to a high level before setting DCMRWF1, will this high level be maintained?

If you enable padkeeping before going to standby mode(write DCM_GPR->DCMRWF1[STANDBY_IO_CONFIG] = 0. Which is default register value no matter PKE of SIUL2 is set or not), but you did not disable it after wakeup, the SIUL2 module can not be initialized again.

This is tricky since our chip design enabled this padkeeping feature by default. If you don’t need the padkeeping function while the MCU needs to go to standby mode and wakeup, you need to write 1 to this bit anywhere and leave it alone.