Hello Sir,
Please check the photo of WKPU registers,
I set 5 WKPU source,
4 Falling-Edge Event Enable, and 1 Rasing-Edge Event Enable,
WIFEER_64 = 0x00201C00
WIREER_64 = 0x00000200
the problem as below:
I want WISR_64 = 0x00200000 then WKPU source is 0x00200000,
but WISR_64 = 0x00201C00 ,actually;
I test again,
I want WISR_64 = 0x00001000 then WKPU source is 0x00001000,
but WISR_64 = 0x00201C00 ,actually;
It alway WISR_64 = 0x00201C00 then any Falling-Edge WKPU source
Comparative testing,
I set 5 WKPU source,
0 Falling-Edge Event Enable, and 5 Rasing-Edge Event Enable,
WIFEER_64 = 0x00000000
WIREER_64 = 0x00201E00
I want WISR_64 = 0x00200000 then WKPU source is 0x00200000,
and WISR_64 = 0x00200000 ,actually;
I test again,
I want WISR_64 = 0x00001000 then WKPU source is 0x00001000,
and WISR_64 = 0x00001000 ,actually;
WISR_64 correct for any Rasing-Edge WKPU source.
Thanks.
解決済! 解決策の投稿を見る。
Hi all,
Why the wake-up source read by the customer is inconsistent with the actual wake-up source is caused by the function of Pad_keeping.
Then you need to pay attention to the use of the Pad_keeping function:
As long as there is a GPIO falling edge to wake up the MCU in the project, the Pad_keeping function must be enabled. The reason is that if Pad_Keeping is not enabled before sleep, once the MCU wakes up, all GPIOs are in a high-impedance state, and the corresponding MCU GPIO internal circuit generates a falling edge, so it will mistakenly cause WISR_64 or WISR to be set to 1 corresponding to wake-up.
Customers can directly read the values of WISR_64 and WISR at the beginning of the main function, and then disable the Pad_Keeping function.
Usually, it is recommended that customers enable the Pad_Keeping function, and then read the values of WISR_64 and WISR after waking up, and then disable the Pad_Keeping function.
Thanks!
BR,
Shuang
Hello @SJWL,
Do you set STANDBY_IO_CONFIG before you read the flags?
If so, can you read the flags first and set the STANDBY_IO_CONFIG after that?
Thank you,
BR, Daniel
Hello,
I had the same problem with S32K312, set the external wake source to rise edge trigger, everything was fine, but set to fall edge trigger, all the WISR set as the wake source corresponding bit was set to 1, that is, all wake sources triggered the wake
Hi all,
Why the wake-up source read by the customer is inconsistent with the actual wake-up source is caused by the function of Pad_keeping.
Then you need to pay attention to the use of the Pad_keeping function:
As long as there is a GPIO falling edge to wake up the MCU in the project, the Pad_keeping function must be enabled. The reason is that if Pad_Keeping is not enabled before sleep, once the MCU wakes up, all GPIOs are in a high-impedance state, and the corresponding MCU GPIO internal circuit generates a falling edge, so it will mistakenly cause WISR_64 or WISR to be set to 1 corresponding to wake-up.
Customers can directly read the values of WISR_64 and WISR at the beginning of the main function, and then disable the Pad_Keeping function.
Usually, it is recommended that customers enable the Pad_Keeping function, and then read the values of WISR_64 and WISR after waking up, and then disable the Pad_Keeping function.
Thanks!
BR,
Shuang
Than you for your reply,
The WISR_64 is OK now Following your suggestion.
Thank you very much!
Hi Niuyanlin,
The four internal wake-up sources of S32k3 is not support falling edge wake-up, and support rising edge wake-up. The external wake-up pin can detect rising or falling, so the 60 external wake-up pins are support rising or falling edge wake-up. The next version of S32K3 reference manual will update this information.
Thanks!
BR,
Shuang