Is there a way to determine what event woke us up out of Stop mode (STM32F042K6)?

[Jim Seymour]

On a STM32F042K6 (using the latest CubeMX software and FW_F0 V1.9.0), we have code that goes into "Stop" mode to achieve low power. A pin connected to PA0 (EXTI0) wakes us up.

This all works great. Except that we can get the system into a state where it immediately wakes up after entering Stop Mode. Once it's in this state, a CPU reset does not shake it loose. Only a power cycle fixes it.

Is there a way to determine what is waking us up from Stop mode? I've gone so far as to disable all interrupts (using __disable_irq()) and the problem persists.

Thanks.

[waclawek.jan]

If you use WFI to go to sleep, you want to look at the NVIC_ISPRx registers. It's the interrupt signal arriving into NVIC which wakes up your mcu, not execution of the ISR. __disable_irq() does not disable (mask) interrupts in NVIC - they continue to arrive and set the pending bits - just prevents them to be executed by the processor.

JW

[Jim Seymour]

Thank you.

Unfortunately, that register is zero - both before and after the STOP mode call. The mystery remains. I'm now off to examine the errata - because this sure seems like a chip bug...

[Jim Seymour]

I found some indications that it was the SysTick waking us up - so I suspended it before and resumed it afterwards.

The weird part is that somewhere along the line, we seem to have lost the ability to break our boards. (Previously, we had found that programming with the ST-Link utility would cause it to enter this broken mode - while programming with Keil uVision would not).

All in all, I think we're done exploring this. For now, our code seems to be working fine - and we'll just have to cross our fingers and hope that the SysTick was the real culprit and that we'll never see the problem in the field...

[Jim Seymour]

We have come to a resolution for this issue - and we have convinced ourselves that this is a bug in the chip itself. We were able to duplicate the issue using a STM32F042 Nucleo-32 dev board and a minimal project.

The short version is this: If we program our test code into the board using ST-Link Utiility v3.9.0, the STOP mode will end as soon as the first SysTick interrupt fires. This condition will clear if we cycle power to the board. The workaround is to suspend the SysTick before entering STOP mode.

What's the best way to report this issue to ST? Should I start a new topic on this forum? Or is there a more direct way to send them this information?

Thanks.

[Alex R]

Hi,

The STM32F042 Errata contains the following:

System

2.1.1

Wakeup sequence from Standby mode when using more than one wakeup source

Description

The various wakeup sources are logically OR-ed in front of the rising-edge detector that

generates the wakeup flag (WUF). The WUF needs to be cleared prior to Standby mode

entry, otherwise the MCU wakes up immediately.

If one of the configured wakeup sources is kept high during the clearing of the WUF (by

setting the CWUF bit), it may mask further wakeup events on the input of the edge detector.

As a consequence, the MCU might not be able to wake up from Standby mode.

Workaround

Apply the following sequence before entering Standby

mode:

1.

Disable all used wake up sources

2. Clear all related wake up flags

3. Re-enable all used wake up sources

4. Enter Standby mode

Note:

Be aware that, when applying this workaround, if one of the wake up sources is still kept high, the MCU enters Standby mode but then it wakes up immediately, generating a power reset.

I understand that your are using the Stop mode, but the cause may be the same and the workaround might work for you as well.

[Jim Seymour]

Thanks for the reply. I'm fairly certain this errata doesn't apply - but I haven't tested it.

In our case, the SysTick interrupt wakes us up out of STOP mode - even though the SysTick clock is supposed to be turned off. Once we are in this mode, only a power cycle will change the symptoms. (After only a reset, the problem reoccurs).

In addition, if we program the board directly from Keil, we do not see this problem. It only happens when we program the flash using the ST-Link Utility.

Our actual workaround is to suspend the SysTick before entering STOP mode and then re-enable it afterwards.

So at this point, I think all I need is instructions on how to submit this bug to ST Micro.

[Alex R]

Would you be able to indicate what compiler you are using?

What Keil Programmer and fw version?

What ST-Link version and firmware version?

Are you using the exact binary file (.hex or .bin) with both programmers?

I would not expect that the programmer makes a difference...

If you want to submit your observations to ST, you can create a Support Ticket:

https://my.st.com/ols/

You need to create an account with ST (but most likely you already have one).

[Jim Seymour]

Thanks for the link. I'll definitely submit a ticket.

And yes, it's the exact same HEX file being loaded in. We even loaded in via Keil and verified with the ST-Link utility and they match exactly.

And I would not expect the programmer to make a difference, either. But it does. I'm guessing that it has something to do with how the software resets the processor either before or after the programming.

I am using Keil v5.25.2.0 and ST-Link Utiility v3.9.0, We duplicated the problem on the STM32F042 Nucleo-32 dev board. And if anybody is curious, I'd be happy to upload a project here so others could try to duplicate my experiment.

[Alex R]

For each of the programming utilities (Keil and ST-Link), what is your configuration after programming: run to main, run application? reset?

The latest ST-Link Sw is 4.4.0. Have you tried with that one?