cancel
Showing results for 
Search instead for 
Did you mean: 

stm32F071 + STOP MODE + wakeup + HSI48 = hard fault

henk23
Associate II
Posted on April 05, 2016 at 10:31

For a wearable product we're working on a device that wakes up 160 times a second (for now, will later be reduced to ~10 times per second), does it's thing, communicates with a host and remains in STOP mode for the rest of the time. Because it is battery operated, current consumption is a big issue.

We are not yet certain whether using the HSI48 (instead of HSI at 8 MHz) will have the effect on the average current that we want (if the amount of awake time is linear to the clock speed, then it would as HSI48 goes 6 times as fast with 4.6 times as much current) but while investigating the usage of the HSI48 we ran into an issue.

It seems to be that some hardware samples are more susceptible than others, but what we see, is that after waking up from sleep and going back to the HSI48 results in a hard fault a few instructions after the change to HSI48 is made. I copied code for the change to HSI48 from the STM32F0xx_HAL files, and as far as I can see we're doing everything right. After the wakeup, we do the following:

    /* Enable HSI48 */

    __HAL_RCC_HSI48_ENABLE();

 

    /* Wait till HSI48 is ready */  

    while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSI48RDY) == RESET)

    {

        /* Wait for 48MHz RC clock to be stable */

    }

    /* change to HSI48 */

    MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_SYSCLKSOURCE_HSI48);

    while (__HAL_RCC_GET_SYSCLK_SOURCE() != RCC_SYSCLKSOURCE_STATUS_HSI48)

    {

        /* wait till clock accepted as sysclk */

    }

Is this something that rings a bell to anyone?

#stm32f071-hsi48
3 REPLIES 3
mckenney
Senior
Posted on April 05, 2016 at 14:53

Different device (L152), but similar symptom: mysterious faults shortly after awakening from STOP mode.

It turned out I had forgotten to set the Flash prefetch etc. for the faster clock. It was a bit curious that it ran OK before the STOP, but (only) failed after waking up.

Anyway, that's something to check.

henk23
Associate II
Posted on April 05, 2016 at 15:15

Prefetch was already on, but the flash latency was set to 0, which is a correct setting for SYSCLK < 24 MHz. Setting it to 1 (for SYSCLK >= 24 MHz, obviously) solved the problem.

Thanks! You saved me a considerable amount of time. 🙂

Walid FTITI_O
Senior II
Posted on April 05, 2016 at 18:37

Hi hck,

Try in similar cases to put and compare the suitable code parts implemented in the Library examples in your own code to figure out what is really missing/ wrong.

In your case, for example, SystemClock_Config() in the UART_wakeUP FromStop example will solve your issue.

The example is in

http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF260612

under this path :

STM32Cube_FW_F0_V1.5.0\Projects\STM32F072RB-Nucleo\Examples\UART\UART_WakeUpFromStop

-Hannibal-