cancel
Showing results for 
Search instead for 
Did you mean: 

Is it expected for the PWR_CR1_DBP bit to be disabled on STM32WLE5 during STOP2?

Tim Lamborn
Associate II

I am using the STM32WLE5, and periodically entering and exiting STOP2 mode. The VBAT is connected directly to VCC. I set PWR_CR1_DBP on system initialization, and assume it should not change. On exiting stop mode, sometimes the DBP bit is randomly cleared - causing subsequent writes to the RTC to fail.

My code below is my stop mode entry routine, and I observe the DBP bit being cleared directly after stop mode. Note I have disable IRQ's to eliminate the possibly of this being cleared during an ISR.

void CORE_Stop(void)
{
    CRITICAL_SECTION_BEGIN();
    HAL_SuspendTick();
    MODIFY_REG(PWR->CR1, PWR_CR1_LPMS, PWR_LOWPOWERMODE_STOP2);
    SET_BIT(SCB->SCR, SCB_SCR_SLEEPDEEP_Msk);
 
    if (!(PWR->CR1 & PWR_CR1_DBP))
    {
        // This never occurrs
        __BKPT();
    }
 
    __WFI();
 
    if (!(PWR->CR1 & PWR_CR1_DBP))
    {
        // This seems to occurr randomly
        __BKPT();
    }
 
    CLEAR_BIT(SCB->SCR, SCB_SCR_SLEEPDEEP_Msk);
    CLK_InitSYSCLK(); // Equivilent to SystemClockConfig
    HAL_ResumeTick();
    CRITICAL_SECTION_END();
}

A workaround is obvious - but my question is whether this behavior is expected. It appears to be undocumented.

Is this indicative of some other hardware/firmware issues?

1 ACCEPTED SOLUTION

Accepted Solutions
Tim Lamborn
Associate II

Thanks for the reply Louis.

I have since resolved the issue.

I apologize, I should have updated this post with my findings.

I will describe my conclusions below:

The issue was ultimately caused by errata 2.2.7 in ES0500.

'Voltage drop on the 1.2 V regulated supply when switching MSI to 48 MHz '

In this application I normally disable the MSI, but use it briefly as the clock source for the RNG peripheral @ 48MHz. The startup and shutdown of the MSI was handled correctly in the application. However - when exiting STOP mode, the MSI is selected as the default clock source and restarted. It restarts at the last programmed frequency of 48MHz!!

I disable the MSI in my 'CLK_InitSYSCLK' function, but by then it's too late - the 1.2V regulated supply would have dipped and undefined behavior was invoked. As I dig deeper I found that depending on my compilation settings and timing, this would sometimes cause stack corruption or errors on the instruction bus too.

My solution was to change the default wakeup clock to the HSI using the STOPWUCK bit.

Since then I have had no further issues.

Regards,

Tim Lamborn

View solution in original post

3 REPLIES 3
Louis AUDOLY
ST Employee

Hello @Tim Lamborn​ and welcome to the community,

I did some tests and it seems that there is an error of reading just after exiting the low power. If you check the value of the register PWR_CR1, and specifically the bit DBP, you will see it stay at 1.

Also, you do the same test in the function PWR_ExitStopMode(void) you won't enter in the if.

So i don't think there is an issue regarding this bit changing after stop2, but we have to understand why you enter this case.

I hope this help you

Regards

Louis

Tim Lamborn
Associate II

Thanks for the reply Louis.

I have since resolved the issue.

I apologize, I should have updated this post with my findings.

I will describe my conclusions below:

The issue was ultimately caused by errata 2.2.7 in ES0500.

'Voltage drop on the 1.2 V regulated supply when switching MSI to 48 MHz '

In this application I normally disable the MSI, but use it briefly as the clock source for the RNG peripheral @ 48MHz. The startup and shutdown of the MSI was handled correctly in the application. However - when exiting STOP mode, the MSI is selected as the default clock source and restarted. It restarts at the last programmed frequency of 48MHz!!

I disable the MSI in my 'CLK_InitSYSCLK' function, but by then it's too late - the 1.2V regulated supply would have dipped and undefined behavior was invoked. As I dig deeper I found that depending on my compilation settings and timing, this would sometimes cause stack corruption or errors on the instruction bus too.

My solution was to change the default wakeup clock to the HSI using the STOPWUCK bit.

Since then I have had no further issues.

Regards,

Tim Lamborn

Louis AUDOLY
ST Employee

Hello Tim,

Thank you for your update, this will help other customers !

Happy you manage to find a solution to your issue.

Have a good day

Regards

Louis