2024-10-25 06:58 AM - edited 2024-10-25 07:02 AM
I am working with STM32 U575/U5A5 series of STM32 controllers in low power mode. I have programmed the controller to enter into Stop 3 mode and wake from stop3 mode based on wakeup Pin(High on PF2). With this implementation issue what we observed is once immediately flashing hex file into controller using STlink programmer, Controller is entering in stop3 mode but it is not waking up from stop3 mode even after low to high transistion on wakeUp pin(PF2). If I remove the power and connect it back, it is working as expected enterning into stop mode 3 and waking up from stop mode 3 on low to high transistion on wakeUp pin(PF2) all the time.
The question here is why for the first time after flashing hex file into controller, entering into stop3 mode but not waking up from stop3 mode and requires power reset?
low power mode is configured as follows:
2024-12-16 05:33 AM
Hello @mohan-ltts
Did you try with the latest version (2.18.0) of STM32Cube programmer please.
2024-12-17 04:56 AM
Hello @Saket_Om
Thanks for your reply. I didn't try with version 2.18.0. I will try and let you know the feedback.
Can you please also tell me when this issue is possible? Like some bit is set/cleared before entering into Stop3 mode this is possible like that if you share some information i will debug and share you the update.
Thanks,
Mohan
2024-12-17 10:14 PM
any updates on this ticket?
2024-12-19 06:04 AM - edited 2024-12-20 12:19 AM
Hello @mohan-ltts,
Using this ST example STM32CubeU5/Projects/NUCLEO-U575ZI-Q/Examples/PWR/PWR_LPMODE_RTC at main · STMicroelectronics/STM32CubeU5 with your configuration does not cause the issue you mentioned. It works fine without the need for a reset.
As mentioned by @Imen.D, please redefine the PWR_S3WU_IRQHandler to wake up the system as shown below.
This scenario was tested with IAR, STM32Cube programmer v1.17.0 and STM32Cube programmer v1.18.0.
Please try to use the newer versions as they are more up-to-date and can help avoid any potential issues.
With Regards,
2024-12-23 10:15 PM
Hello @ASEHST
Thanks for your reply.
Not sure why you are not able to reproduce this issue, i'm able to reproduce this issue every time with STMcubeprogrammer v2.12.0.
As per my understanding some bit is set or cleared in some register after flashing the code because of which intruppt is not getting triggered. But after power cycle, register might be set to default values or configured properly so it is working as expected. So i wanted to know which registers and all we need to check before entering into stop mode so that we will not get this issue.
I verified WUCR1, WUSR and SR registers and i don't see any issues.
Thanks,
Mohan
2024-12-24 08:00 AM
Hello @mohan-ltts,
Using the NUCLEO-U575ZI-Q and updating our example PWR_LPMODE_RTC with your code, we were unable to reproduce the issue.
To assist you more effectively, could you please provide us with your project? Additionally, please specify the board you are using.
With Regards,
2024-12-26 09:47 PM
Hello @ASEHST
Can you please flash the attached binary in NUCLEO-U575ZI-Q board using STMcubeprogrammer v2.11.0 and STMcubeprogrammer v2.17.0 and share me your observation?
Binary is generated from PWR_LPMODE_RTC example and SYSTEM_STOP3_MODE is enabled.
If you flash the code using STMcubeprogrammer v2.11.0, you can see LED is Turn ON continuously which means it is not entering into STOP3 mode and it will work as expected if you power cycle once after flashing. This behaviour you will not see when you flash the code using STMcubeprogrammer v2.17.0.
Can you please try and let me know your observation?
Thanks,
Mohan
2024-12-27 08:35 AM
Hello,
Please ensure that you suspend the SysTick interrupt before entering STOP mode as shown below:
With Regards,
2024-12-27 08:43 AM
SysTick is suspended and binary is generated from PWR_LPMODE_RTC example only, so it is already taken care in that example.
Thanks,
Mohan
2024-12-30 07:42 AM
Hello @mohan-ltts,
Could you please try to implement the attached files in your project?
These files include our modifications, which work as expected. You can compare them with your implementation.
With Regards,