I am having the exact issue experienced by Carole Jacquinot in this post: https://community.st.com/s/question/0D50X00009XkWxASAV/why-there-is-an-increased-current-consumption-after-3-minutes-during-stop-mode-with-rtc-with-hal-driver
Some additional information in my situation is that it has nothing to do with I/O pins. They are all accounted for. If I do a reset, configure the I/O and then go directly to sleep, the high-current behavior does not occur. Any ideas?
Please post a trace of the supply current - as Carole Jacquinot did.
Do you have a timer or Watchdog that could explain the 3 minutes (ie, 180s)?
"in my situation ... it has nothing to do with I/O pins"
how have you verified that?
"If I do a reset, configure the I/O and then go directly to sleep, the high-current behavior does not occur"
So look at what your "real" code does in addition to that test case.
I discovered the source of this issue. It is a problem with the way the ADC peripheral is de-initialized in Cube. Reversing the initialization does not return the ADC to its original reset state. You have to perform an ADC hardware reset, or it will start to draw current about three minutes into a sleep state. This problem is likely rooted in a silicon error, because a hard reset should not be necessary.
The way to fix it is to go to the HAL_StatusTypeDef HAL_ADC_DeInit(ADC_HandleTypeDef* hadc) function and find the lines:
/* Reset register CALFACT */
hadc->Instance->CALFACT &= ~(ADC_CALFACT_CALFACT);
And directly after, add the lines:
This will reset the entire ADC system, so if you have other ADC processes going, you will want to consider this.
I proceed to reproduce the issue based on our HAL examples but did not observed any current consumption variation after couples of minutes. May you please share a minimized project you have used ?
Thanks in advance for your help,
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.