Everything works fine but when I try to use HAL_PWR_EnterSLEEPMode (PWR_MAINREGULATOR_ON, PWR_SLEEPENTRY_WFI) to save some power during non-activity, the system crashes, does not make it out of sleep mode.

The program counter ends up at line 130 in startup_stm32l152xe.s line 130 b Infinite_Loop which seems to be the WWDG_IRQ handler. The watchdog is not enabled and what I have found so far indicates that this is caused by an interrupt that is not handled. I have not been able to find a cause. I cannot find any interrupts enabled other than the what I am intending to use.

I am probably making a rookie mistake but would appreciate any help/pointers.

It seems you are in debug mode since you notice a jump in the file startup.s.As you put the core in Sleep mode by the wfi instruction, if you are in debug mode it is quite normal that you lose communication between your mcu and your environment (IDE) which tells you that the stm32 is no longer responding.What you see next in the startup.s file is then indeterminate!Before calling the HAL_PWR_EnterSLEEPMode(), you have the option to keep the debug active in sleep mode using the function below:

I am using the STM32Workbench, the Nucleo L152re has the built in ST-Link.

The system has been generated with CUBEMXL1, I made a small change to the SPI driver to get the select line to go high between SPI operations.

I am also using the serial wire viewer as a standalone output for some diagnostic print information.

The project is in its initial stage of running a wireless device (DecaWave UWB radio) using a polled SPI interface with interrupts from the radio on EXTI0. The radio is running fine and I am getting correct debug info on the serial wire viewer.

I am going to use a timer to kick of transmissions at regular intervals that need to be synchronized with a master (anchor radio) and have a TIM6 with interrupt set up to do that, although the timer just blinks an LED for now.

Everything works as expected until I try the following.

My next step was to reduce power and turn of the processor clock when there is nothing to process.

I inserted the following in my idle processing loop

I experimented with some debug variables and found that the system enters the WFI instruction in HAL_PWR_EnterSLEEPMode but never makes it out, the system freezes/crashes.

When I suspend the debugging the program counter points to line 130 in the code below, suggesting an unhandled interrupt.

Looking at the NVIC and external interrupts It seems that the system crashes when the next EXTI0 interrupt is coming in, but that works fine without the sleep attempt.

I must be missing something basic, I have not been able to find someone else having this issue and I have spent quite some time reading documentation etc.

I am not expecting any debug output when the system is in sleep mode, that has not been an issue (yet).

Attachments

It seems you enter in Hardfault Handler (image[1].png) because an interrupt event is not correclty handled.

Note that wakeup Pin is dedicated to wake-up from Standby.

Could you create and test a basic firmware that performs the following functions:- Configure the User button in Input EXTI rising Edge mode.- Configure LED2 PA5 in Output PushPull mode.

Do not use other peripherals.

In the main function and into the while (1) bloc- Make a simple Toggle of LED2 PA5 say 10 times to make sure your mcu is in run mode.- Then disable the Systick (with HAL_SuspendTick ();)- Finally put the mcu in Sleep mode, the wake-up from sleep should appear when the User Button is pressed.- Reactivate the Systick (HAL_ResumeTick ();)

Here an example:

intmain(void){

HAL_Init();

while(1){

/* User push-button will be used to wakeup the system from SLEEP mode */BSP_PB_Init(BUTTON_USER, BUTTON_MODE_EXTI);/* Configure LED2 */BSP_LED_Init(LED2);

I have been distracted with another project for a few days. I have tried the simple interrupt experiment.

I did let CUBEMX generate the interrupt handler for the pushbutton pin (GPIO 13 on the Nucleo L152RE)

Using STM32 workbench I got some weird behavior setting the breakpoint that did not make any sense.

The debugger claims to set the breakpoint in the proper location but the system halts when going into the clock setup routine which follows main immediately after where the breakpoint is supposed to go.

Besides that, the sleep instruction is ignored (Systick is suspended).

In contrast to my previous experiment, without debugger attached, the sleep instruction is still ignored and the LED keeps blinking. I am thinking that I corrupted my installation and need start from scratch.

I switched over to Atollic Truestudio 7.1, the results are different. The processor also halts as intended but does not recover after the pushbutton and never makes it to the breakpoint.

It ends up in the same hard error handling routine. However, in this case without debugger attached the experiment behaves as intended, goes to sleep and wakes up for another set of blinks after pushing the button.

I will keep experimenting and let you know if I find something. For the time being I am continuing without the sleep mode and will add that when going to the final hardware setup.

Hello everyone, I just encountered the same problem on my Nucleo-L053R8. I'm using interrupts other than EXTI but basically the same thing happens. When debugging, the MCU enters HardFault_Handler once a wake-up event occurs. It may be useful to note that when this happens the MCU must be re-powered for the program to start working - disconnecting the debug session and a HW reset are not enough.

Recently at work I've worked on a project which uses an L152RD and I did not have any issues with it so maybe I'll try some configuration from that project and get back to you if I have any luck.For now I'll just say that the L152 project uses V-reg on Range 3, no HSE and sleeps in stop mode while my test program on the Nucleo uses Vreg Range 1, HSE and LSE, and normal sleep (WFI with no other options)

I think you're missing the point. The debugger does not disconnect and even if it did it's not the issue we're talking about. The problem is the MCU itself enters HardFault on a wake-up event if the debugger is connected;

However your suggestion yielded...well...something...When LL_DBGMCU_EnableDBGSleepMode(); is used the program doesn't work even after a power cycle.

BTW, I'm using SW4STM32 (with GCC) but I don't think it should matter. As I said my project on L152 works flawlessly with and without debugging.

Perhaps, but if conventional methods got you to a solution you wouldn't be here, so humour me a little.

>>The debugger does not disconnect and even if it did it's not the issue we're talking about.

Yes, but the debugger is far from ideal, and tends to distort what's happening. If you can take it out of the equation, you might better see what's really happening.

>>The problem is the MCU itself enters HardFault on a wake-up event if the debugger is connected;

Ok, and what does the fault handler tell you about the problem? Do you have any register content, or stack data? Does it fault in a consistent place?

There are definitely issues with the flash/prefetch with respect to this on one or more of the devices, this thread was for an L1 device, the L0 hopefully addressed some of the original issues, but they are entirely different parts, using a different core, and the compiler is going to generate different code. The debug interface is also rather different.

Well, I've found a reliable way to replicate the problem and a possible workaround but my post is "Currently being moderated"...Edit: And I've just checked that disabling prefetch does not seem to make any difference.

Found it! And it ain't pretty...Note: I don't currently know if it's the same issue on L152 as it is on my L053.

The code that wouldn't work for me was a FreeRTOS port on which I wanted to try the tickless idle mode.Eventually I generated a new project with CubeMX that would toggle an LED in EXTI ISR after pushing a button and would enter sleep mode in the main loop. And there were no issues. I verified that both projects have all clocks and everything set and found no problems.So I returned to the FreeRTOS based project and set a breakpoint right after the WFI instruction and it did not crash. So it got me thinking...The way this FreeRTOS port enters sleep is:

and the code would no longer work (HardFault on wake-up).Because inserting a breakpoint on the ISB instruction caused the program to work (and halt every time the breakpoint was hit) i tried inserting a NOP instruction between WFI and ISB and it solved the problem!When I started writing this post I initially wrote (and thought) that you need to wait between executing WFI and allowing the core to enter Handler mode but it can't be it.I don't think I really understand what is going on. I think it may be related to the memory alignment of some instructions (check the examples below).Here are some examples of code that works:

// This may be repeated an odd number of times (1, 3, 5 etc.)__asm volatile("nop");

__asm volatile("wfi");__asm volatile("cpsie i");// 4__asm volatile("cpsid i");__asm volatile("dsb");__asm volatile("wfi");// Again it only works with odd number of NOPs__asm volatile("nop");__asm volatile("isb");__asm volatile("cpsie i");// 5__asm volatile("cpsid i");__asm volatile("dsb");// x1, 3, 5 etc.__asm volatile("nop");__asm volatile("wfi");// If there's an odd number of NOPs before WFI, there can be any number of NOPs// after WFI unlike in the previous example__asm volatile("nop");__asm volatile("nop");__asm volatile("isb");__asm volatile("cpsie i");

I'm back with more bizarre news! I took one of the old prototypes from work that uses L152, compiled the same kind of code and even weirder things happen. At this point I'm thinking either the FreeRTOS's port.c file supplied with STM32 firmware packages is incorrect or something is seriously wrong with these micros. I don't have enough experience with Thumb assembly to determine that.So again I added this code to the CubeMX-generated code:

and I toggle a GPIO line in EXTI ISR to quickly determine whether it still works.

I put a breakpoint in the ISR which wakes the MCU up and found that the stacked PC is a nop instruction (padding) after "main" function. If I put a breakpoint on the instruction after WFI, press the button (which causes the breakpoint to be hit) and resume the program (with a breakpoint still present in the ISR) I can see that the stacked PC is correct.Does anyone know what could possibly be happening? This could be problematic because as I said previously, on L0 it would stop working not only when the debugger was attached but also when debugging in sleep mode was simply enabled.E.g. by:

LL_DBGMCU_EnableDBGSleepMode();

I just realized that I might have screwed up my previous test on the L0 because I think I somehow forgot that CubeMX enables SysTick and additional interrupts might have skewed my view. I'll try again shortly. Maybe it's the same problem.

Edit: Nope, the L053 HardFaults even without any interrupts and as I said before the stacked PC points to the ISB instruction.

Update (for the L152): I uncommented the nop instruction (visible in the attached screenshot) and now it does not get to the EXTI ISR - it just HardFaults with: SHCSR == 0, CFSR == 0x8200 (which is BFARVALID | PRECISERR), HFSR == 0x40000000 (FORCED)DFSR == 0xbBFAR == 0xb005f851

We are also attempting to track down the cause of a hard fault on an STM32L476 that seems to occur on the exit of Stop Mode 1. We have the WFI() wrapped by DSB() and ISB() instructions similar to the FreeRTOS implementation. Adding NOP(s) after the WFI() seems to prevent the problem.