2024-11-08 12:36 AM
Hi every body,
I'm using STM32U031 in my project.
Since the project is a low power consumption application, so I set MCU running in shutdown mode.
The MCU will exit shutdown mode by rising edge of wake-up pin.
I ran into an issue with the MCU exiting shutdown mode:
The MCU can exit from shutdown mode to running mode only when the width of rising edge of wakeup pin is greater than 70ms. This is unacceptable.
Please help me to solve this problem, Thanks.
2024-11-08 10:59 AM
This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.
2024-11-12 06:03 AM - last edited on 2024-11-12 06:36 AM by Viktor POHORELY
Hi @xinmeng_wit,
I just tested the shutdown wakeup with EXTI GPIO pulses with length of 35 us and it works correctly. Could you please let us know from where this 70ms in your request comes from?
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-11-12 05:50 PM
Hi Bubbles,
The time of 70ms is the width of purple signal. It is 35us indeed in your picture.
After testing and debugging, I found the time of 70ms can be decreased to 4ms by adjust HCLK frequency from 1MHz to 8MHz and disable uart print function.I guess it might be related to the time consumed by the task.
Could you help me to add some time-consuming tasks (ex. printf, flash erase/write etc. )to test? Thank you.
2024-11-13 08:14 AM
Hi @xinmeng_wit ,
so what you are looking for is to minimize time between wakeup and the code execution.
Try putting GPIO signal as the first thing in the main(). Enable GPIO clock, put corresponding MODER to 01 and write ODR of that pin. This way I easily tested that user code is active as soon as 200-300us after wakeup.
If you can confirm this, then your problem is the initialization code. Try using code profiler to determine where to optimize.
If you cannot get to have this confirmation pulse soon after the wakeup, there are three explanations:
1) Reset temporization is too long. Make sure not to use excessive capacitor on your reset pin, follow the DS recommendations.
2) There is too much initialized volatile memory content. Typically if you use a lot of code executed from SRAM, the compiler and linker will initialize all that by copying from flash. That may take a lot of time in some cases.
3) the ST bootloader is activating and waiting for a bit before executing user code. Try disabling that in option bytes.
BR,
J
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-11-17 10:18 PM
Hi @Bubbles ,
To reproduce my problem, I simulated it on the NUCLEO-U083RC development board.
I use PA0 as wakeup pin and If the MCU is awakened by PA0, the LED will be lit for 500ms.
This code has reproduced my problem.
The LED will be lit when the width of pulse is greater than 2ms.
The LED will not be lit when the width of pulse is about 100us.
The attached is my project.
Thank you.
2024-11-19 04:20 AM
Hi @xinmeng_wit,
the picture you put into your post is not precise. Did you try measuring the pulse using a digital oscilloscope?
BR,
J
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-11-20 01:30 AM
Hi Bubbles,
The signal of PA0 is generated by another NUCLEO board. The signal should be ok.
I think the precision is not very important. What's important is that you can reproduce my problem. That is, given a large pulse width, the LED can be lit, and given a small pulse width, the LED cannot be lit. As for the specific width value, it can be reproduced and then measured in detail.
So now my focus is on whether you can reproduce this problem with my project code.
Thanks.