STM32 : minor update in sleep HAL file #3742
Conversation
|
I'd prefer we add a unified debug method before taking this. Sure there are examples where this exists but I'd suggest we dont take more, rather, start a common implementation. |
jeromecoutant
force-pushed
the
PR_SLEEP
branch
from
113d79b to
053072c
Compare
|
Debug messages have been removed, and rebase done. |
|
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
I think the failure was caused by a test taking abnormally long to get started and it "TIMEDOUT" before it could finish. I will restart the test. /morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputExample Build failed! |
|
Here is the step that failed: http://mbed-ci-master-2.austin.arm.com:8081/job/examples_build_matrix/516/target=UBLOX_EVA_NINA,toolchain=IAR/console The error was caused by what looks like a very intermittent bug in Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-23271 It seems that lightning has struck twice on this pr 🙄 From the comment chain of the Jenkins issue, it looks like this was fixed in Jenkins version 2.35. We're currently running an earlier version of that. I would prefer to get through the 5.4.0 release before upgrading our infrastructure unless it's absolutely critical. For this reason, I'm again just going to restart the build. /morph test-nightly |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
| @@ -84,6 +85,10 @@ void hal_deepsleep(void) | |||
| // After wake-up from STOP reconfigure the PLL | |||
| SetSysClock(); | |||
|
|
|||
| TIM_HandleTypeDef TimMasterHandle; | |||
| TimMasterHandle.Instance = TIM_MST; | |||
| __HAL_TIM_SET_COUNTER(&TimMasterHandle, EnterTimeUS); | |||
There was a problem hiding this comment.
Does this mean that ticker is restarted and we resume the ticker from the last known timestamp?
There was a problem hiding this comment.
Hi
Does this mean that ticker is restarted and we resume the ticker from the last known timestamp?
During deepsleep period, ticker is stopped, then ticker is reset during the clock configuration.
There was a problem hiding this comment.
Thanks. For future reference, this type of details is often worth having in the commit message, for a reader (I just guessed this without looking at the reference manual ).
There was a problem hiding this comment.
Note: This is one of the things we should cover in the API docs, as deepsleep in many cases would stop us ticker clocks/resets, thus should it resume time or not (currently user's assumption must be made).
Description
Remove compilation warning
Debug capability added
Set back US counter after deepsleep period
Status
READY