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').

[Tesla DeLorean]

Posted on April 11, 2018 at 15:01

It is a single instruction, but before it moves to the next instruction it has to execute whatever code is pending. ie Does the interrupts, then comes back to the foreground.

So you're connecting to some custom L0 board via the NUCLEO-F103RB SWD header. Can you make sure you have current firmware on the ST-LINK?

[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.

[Tesla DeLorean]

Posted on April 12, 2018 at 19:34

Debugging through the keyhole is always a PITA, there isn't enough visibility into whats going here with the level of context or demonstrability provided.

With GNU/GDB and OpenOCD it is more sketchy as to the version and build specifics, and what's in the script.

Things with the STACK or RAM are higher up my list of potential suspects, along with the other 99.999% of the code I can't see.

Other things would be the handling of the BKPT here, and placements of breakpoints by the debugger