Description
Description of defect
Expected behavior
Normal use of HAL_PWR_EnterSLEEPMode()
Actual behavior
On certain occasions the device crashes with a hardfault after calling HAL_PWR_EnterSLEEPMode(). This is however only when running with the debugger. After some extensive testing it seems that sometimes the flash has some glitches and the stack is popped an additional time causing the SR to be out of sync.
The first image shows the disassembly of the routine as it should be and this functions without issue. The live watch is to indicate that the flash is indeed read correctly.
This image shows the disassembly but this time with wrong instruction according to the live watch. The new instructions are an additional WFE and an additional POP {R4}. The instructions down below also execute and the BX LR on line 0x80097F2 returns with the SR off by 1 causing the hardfault later on.
Target(s) affected by this defect ?
STM32L072CZ
Toolchain(s) (name and version) displaying this defect ?
IAR 8.11.2
What version of Mbed-os are you using (tag or sha) ?
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
n/a
How is this defect reproduced ?
I am running mbed in Tickless mode. To be able to do this I have defined the mbed_get_m0_tick_irqn as the LCD_IRQn since I won't use that one.
The only thing I do in main is set the ULP bit in the PWR->CR register and add a call_every to the shared queue to toggle a led and wakeup every so often:
DigitalOut led1(PA_3);
EventQueue *pQueue = mbed_event_queue();
extern "C"
{
IRQn_Type mbed_get_m0_tick_irqn()
{
return LCD_IRQn;
}
}
void Led1On()
{
led1 != led1;
}
int main()
{
PWR->CR |= 0x200;
pQueue->call_every(5000, Led1On);
return 0;
}
After that the only thing running is the idle thread after returning from main.
The issue only occurs when MBED_DEBUG is defined or if deep sleep is locked. This means HAL_PWR_EnterSTOPMode is not affected.
Not setting the ULP bit solves the issue but this means we can't go low power as we want to.
Adding a couple of nops after the wfi seems to solve the issue, just as was the case in #5396.
The only other reference I could find online was this: https://community.st.com/thread/41602-stm32l1-hardfault-when-returning-from-wfi-only-when-debugger-attached which wasn't answered but seems to be the same issue as I am having now.