What's causing this power spike in STM32 low power mode
I can't speak about mbed specifically, but the general idea is that sleep() causes the execution of the current process to pause for some number of seconds, or indefinitely if no argument (equivalent to an argument of 0) is given.
In a multiprocess environment, that means that it simply yields the CPU to other processes. If there are no other processes ready to run, the OS may or may not put the CPU into a low-power state while waiting for interrupts — it depends on how the idle() task is written. This would not generally be the lowest-power state available on the CPU, however, since it wants to wake quickly when interrupts occur.
In your case, it appears to be waking up once a second to handle the system timer tick.
If you really want to get into a lower-power state, there are generally platform-specific calls for that, and that's exactly the sort of thing the HAL is for. You shouldn't avoid it, you should learn it.
After a quick search, I discovered that the documentation here: APIs - power management discusses this specifically.
As explained in the documentation, the following drivers can prevent deep sleep:
- Ticker
- Timeout
- Timer
- SPI
- I2C
- CAN
- SerialBase
If you need to identify what is blocking deep sleep, you can build from the command line, and enable the verbose debugging - even though it seems you do not have any in your example.
You can also review the tickless documentation. I believe this mode is relatively new, so it is possible that your platform has some problems in the HAL.
If you enable tickless mode (via MBED_TICKLESS=1) and just pause the thread (via wait_ms(10000)) you won't see any spikes, and the MCU will stay in Stop mode (at least on my STM32F4 board).