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.

[Jim Seymour]

I have not tried 4.4.0. I'll try to make some time to test this later today...

(Though I don't see this as a bug in the software - so even if it "works", it doesn't negate the bug in the chip).

[Jim Seymour]

Sorry. Forgot to answer your question...

In Keil, the option is "Reset and Run" (per Flash / Configure Flash Tools: Debug tab: Use ST-Link Debugger / Settings : Flash Download tab / Download Function).

In ST-Link, the option is "Run application" (as invoked from the Target / "Automatic Mode" function). (Note: I don't recall whether the Connect / Program / Disconnect method causes the bug to happen or not).

[Jim Seymour]

I just tried 4.4.0 and was able to duplicate the problem.

One of the weirder parts of this issue is that if I duplicate the problem by programming with ST-Link, then reprogramming with Keil does NOT clear the bug. Only a power cycle clears it.

If anybody is brave enough, I'm attaching a Keil uVision project (built with the latest version of STM32CubeMX). To duplicate the problem, you'll need to build the project in Keil, then program the STM32F042 Nucleo-32 dev board using the ST-Link Utility. (I'm also uploading just the HEX file if you don't want to build the whole project).

By monitoring pins D8 (PF1 on the CPU) and D13 (PB3 on the CPU), you can see the failure.

PF1 is brough High just before entering STOP mode and brought Low after waking up.

PB3 is pulsed in the SysTick ISR.

The main code simply enters STOP mode once per second in a loop. On a working system, you will see a number of SysTick interrupts, followed by the PF1 going high and staying there (since nothing wakes it up).

When the bug occurs, PF1 will go High and then go Low on the next pulse of PB3.

[Jim Seymour]

Looks like the forum here only allows one attachment per post. Here's the HEX file...

[Alex R]

To enter the Stop mode, the datasheet indicates that:

Note: To enter Stop mode, all EXTI Line pending bits (in Pending register

(EXTI_PR)), all peripherals interrupt pending bits and RTC Alarm flag must

be reset. Otherwise, the Stop mode entry procedure is ignored and

program execution continues.

If the application needs to disable the external oscillator (external clock)

before entering Stop mode, the system clock source must be first switched

to HSI and then clear the HSEON bit.

Otherwise, if before entering Stop mode the HSEON bit is kept at 1, the

security system (CSS) feature must be enabled to detect any external

oscillator (external clock) failure and avoid a malfunction when entering

Stop mode.

Have you check that these conditions are met?

Have you tried the code on other processors (F4, or L0, L4)?

(Sorry I don't have an F042 Nucleo or any F0 processor to test)

[Jim Seymour]

Thanks. In my case, though, the CPU does enter STOP mode - for a little while. It stays there until the next SysTick interrupt - so I don't think the scenario you mention is applicable.

I've opened a ticket with ST - so perhaps they can figure out whether it really is a bug in the chip (as I suspect).