`SysTimer::set_wake_time` incorrectly assumed that the `SysTimer`s tick
count and the underlying HAL timer had the same zero base. This normally
holds, at least approximately, in RTOS builds where the HAL timer starts
from zero at the same time the SysTimer is initialised.
But in bare metal builds, the HAL timer could be started some time
before the SysTimer, giving a significant discrepancy.
Beyond that, there's no requirement for HAL timers to start from zero in
the spec.
Record the HAL timer start time to get the conversion right.
Suggested-by: @kjbracey-arm
Replace the sleep_manager_can_deep_sleep() with !_deep_sleep_locked.
Indeed, if we know we've taken the lock because we're using us_ticker,
no need to do the early wake.
Updated comments accordingly.
When next SysTimer wake-up is scheduler far enough, always consider
that deep sleep may be entered and program an early wake-up.
So that even if deep sleep is only allowed some time later, it can be
entered. If not doing this, then the deep sleep would be prevented by
SysTimer itself and may not be entered at all.
This has been proved to happen in a simple blinly example.
Kevin Bracey
Laurent Meunier
Hugues Kamba
George Psimenos