STM32 Low Power Timer feature updates #5459
Conversation
|
| NUCLEO_F091RC-ARM | NUCLEO_F091RC | tests-mbed_drivers-lp_timeout | OK | 62.38 | default | |
targets/TARGET_STM/rtc_api.c
Outdated
| void rtc_init(void) | ||
| { | ||
| RCC_OscInitTypeDef RCC_OscInitStruct = {0}; | ||
| RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0}; | ||
|
|
||
| if (rtc_inited) return; |
There was a problem hiding this comment.
Is this correct way to RTC init check? Shouldn't this rather check RTC register if RTC is already running ?
If an app goes through reset, this could lead to restarting RTC to loose the time as rtc_inited would become 0 during startup again. But RTC is running (keeping time).
| * CK_SPRE_16BITS: 1s < wakeup period < (0xFFFF+ 1) x 1 s = 65536 s (18 hours) | ||
| * CK_SPRE_17BITS: 18h+1s < wakeup period < (0x1FFFF+ 1) x 1 s = 131072 s (36 hours) | ||
| */ | ||
| uint32_t WakeUpClock[6] = {RTC_WAKEUPCLOCK_RTCCLK_DIV2, RTC_WAKEUPCLOCK_RTCCLK_DIV4, RTC_WAKEUPCLOCK_RTCCLK_DIV8, RTC_WAKEUPCLOCK_RTCCLK_DIV16, RTC_WAKEUPCLOCK_CK_SPRE_16BITS, RTC_WAKEUPCLOCK_CK_SPRE_17BITS}; |
There was a problem hiding this comment.
Do you think we can get more details in the commit message regarding this calculation of WakeUpClock ?I could think of how this is improving the time ( similar to what the comment says about, that this is choosing the best divider for RTC clock based on the period (if I read the code correctly)) ?
jeromecoutant
force-pushed
the
PR_LPT_RTC
branch
from
46115e2 to
f6966be
Compare
jeromecoutant
changed the title
|
@0xc0170 Did also full rebase Tested with LSE and LSI configuration with all STM32 families. Thx |
jeromecoutant
force-pushed
the
PR_LPT_RTC
branch
from
f6966be to
1bfc307
Compare
targets/TARGET_STM/rtc_api.c
Outdated
| HAL_RTC_SetDate(&RtcHandle, &dateStruct, RTC_FORMAT_BIN); | ||
| HAL_RTC_SetTime(&RtcHandle, &timeStruct, RTC_FORMAT_BIN); | ||
| if (HAL_RTC_SetDate(&RtcHandle, &dateStruct, RTC_FORMAT_BIN) != HAL_OK) { | ||
| printf("HAL_RTC_SetDate error\n"); |
There was a problem hiding this comment.
could this use debug function rather than printf ? Or turn to error or?
|
/morph build |
Build : SUCCESSBuild number : 569 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 182 |
Test : FAILUREBuild number : 387 |
jeromecoutant
force-pushed
the
PR_LPT_RTC
branch
from
a336d34 to
5dee163
Compare
|
Conflict solved Tests are OK for NUCLEO_F401RE on my side: | NUCLEO_F401RE-ARM | NUCLEO_F401RE | tests-mbed_drivers-lp_timeout | OK | 24.12 | default | |
|
/morph build |
Move LSI configuration from macro to config part Add missing boards to the LPT supported targets
Removed unnecessary part
Add RSF synchro during init Set a better WakeUp clock for long wake up period in order to stay in sleep mode Use rtc_isenabled function before init as rtc_init is called at each set_time call
RSF synchro after deepsleep is not specific to Low Power Timer feature And we have to check if RTC is configured before synchro
jeromecoutant
force-pushed
the
PR_LPT_RTC
branch
from
5dee163 to
17a5484
Compare
|
@0xc0170 |
|
/morph build |
Build : SUCCESSBuild number : 654 Triggering tests/morph test |
Test : FAILUREBuild number : 478 |
Exporter Build : SUCCESSBuild number : 297 |
|
I cant reproduce the error. downloading the binaries from the latest test run, all OK on my device. Same happens for the local run from the latest master. How I reproduced: used binaries from the build above, run /morph test |
Test : FAILUREBuild number : 485 |
|
@kegilbert Can you please help to reproduce the above failure? 😕 |
|
In the CI test bench, does each target start from a "switch off/unplug" state, |
|
@jeromecoutant All targets are always on, we do soft resets after flashing as far as I know. I can unplug/plug in the NUCLEO_F401RE, is this a one off fix or do you need the devices to be disconnected completely before each CI run? |
|
I un/replugged the F401 boards, rekicking off test. |
Test : SUCCESSBuild number : 494 |
Description
Updates done after several internal tests.
Status
READY
Test
RTC and LPT tests have been checked for all STM32 families
#5106 updates have also been verified