Weird behaviour of WFI instruction on stm32L031G6

[Maciej Koz?owski]

Posted on April 10, 2018 at 16:23

Hello,

I found that WFI instruction modify R0 register value. This happens at least on SysTick interrupt. Value, if modified, appears to be mostly 0, but sometimes is random.

WFI behave weird on stm32L031G6, but works ok on stm32L031C4.

Power seems to be ok.

Code showing behaviour:

bkpt

0

movs

r0

,

#8

movs

r1

,

#0

WFI_loop:

/* replace with nop -> works as expected */

wfi

cmp

r0

,

r1

bne WFI_loop

/* this place shall never be reached */

bkpt

1

edit:

Attached full code.

I have just tested it on 6 different chips, only 1 of them works as should.

[Tesla DeLorean]

Posted on April 10, 2018 at 16:57

Suggests either that your debugger is queering things up, or you have an interrupt or task-swap damaging context. Make sure your stack is deep enough for anything executing prior to WFI returning is provided. Perhaps paint the stack so you can see how deep it gets from one side to the other.

[Maciej Koz?owski]

Posted on April 11, 2018 at 13:48

Here is only one interrupt - SysTick.

Replacing WFI with NOP makes things work.

[Tesla DeLorean]

Posted on April 11, 2018 at 14:06

Yes understood the NOP functionality from first post. With WFI it is executing a whole lot of other code, not a single instruction.

Do you have anything to Trace the actual execution?

Are you using a professional debugger?

[Maciej Koz?owski]

Posted on April 11, 2018 at 14:30

I'm using nucleo-f103rb board, openocd + gdb.

I don't understand, wfi have own opcode (Thumb-2). I know about __WFI() defined in cmsis, but it is asm volatile('wfi').

[Thomas Roell]

Posted on April 12, 2018 at 13:09

Did you by chance set the bit to power down the flash in SLEEP mode ?

I had been running into similar issues. Adding 3 NOPS after the WFI solved them all. My issue were more related to not being able to write to AHB/APB first things after WFI though.

[Tesla DeLorean]

Posted on April 12, 2018 at 18:25

However the behaviour here seems more invasive in nature, where CPU registers are getting corrupted, presumably ones automatically pushed/popped off the stack by the NVIC/IRQ system.

I would suspect the GNU/GDB here, and would confirm if adherent behaviour continues to be demonstrated via Keil or IAR toolchains with better validation.

[Thomas Roell]

Posted on April 12, 2018 at 18:49

It could be GNU/GDB, but I am using that one all the time, and I have not run across a problem like that. 

What I have seen is that the instruction following the WFI was simply not executed, sometimes. It was decoded properly (I am assuming based upon the length).

It's however also possible that this is some stack corruption. Simply looking at the stack contents might help to find out whether the register values that got restored from the stack are the expected ones.