DA1469x: Clock time shifts on reboots #3321

apc067 · 2024-10-17T23:40:31Z

If the LP clock's frequency is not an integer multiple of the specified OS tick frequency, the period of OS ticks will be incorrect due to integer division truncation errors (to the tune of almost 1% for RCX), resulting in OS Time
gradually creeping away from the actual time. This PR fixes the issue, by maintaining the fractional OS tick value and advance OS Time accordingly.

This PR also improves on the implementation of the DA1469x clock driver and updates the RTC divider registers after the selected LP clock is calibrated.

kasjer

Number of functions are moved around that makes it harder to see what is new and what was really modified/added.

hw/mcu/dialog/da1469x/include/mcu/da1469x_clock.h

kasjer · 2024-10-21T06:48:35Z

hw/hal/include/hal/hal_os_tick.h

+ *
+ * @param os_ticks_per_sec The number of OS ticks per second
+ */
+void hal_os_tick_calc_params(uint32_t os_ticks_per_sec);


It's not clear why this function is in this header.
It it used only in da1469x code so maybe it should be part of da1469x code.

Looking at the other services in hal_os_tick.c, I still believe this function belongs here. This is a new addition to the API, for the OS tick dividers to be re-tuned (case in point, after an oscillator re-calibration). It can be implemented for the other MCU's as well, on a need-to-do basis.

I'm not convinced.
There is no code (in public repository) that requires this prototype. Even file in this commit does not need this.
If I was to implement this function for other MCU I would not know what is the purpose, why OS needs it and when it should be called.
To make your case it would be nice to have other code that utilizes this functionality. For now this function could be static in your hal_os_tick.c without any prototype.

As a matter of fact, the reason I went thru the trouble of carving this out into a function & adding it to the API is that I wish to use it from our code.

I don't really see why external code would need to call this. This calculates parameters based on current lpclk frequency so it just has to be done after lpclk frequency has changed e.g. after calibration so it can be called from that routine directly.

Actually calling this from da1469x_lpclk_updated should be enough.

hw/hal/include/hal/hal_system.h

apc067 · 2024-10-22T03:34:09Z

Number of functions are moved around that makes it harder to see what is new and what was really modified/added.

I see your concern; I separated the original commit into two, one only rearranges the functions with no changes whatsoever, and the second one adds the missing services to the API.

kasjer · 2024-10-22T06:07:56Z

hw/mcu/dialog/da1469x/src/da1469x_clock.c

+static void
+da1469x_clock_lp_set_rtc_divs(void)
+{
+    /* Please see section 2.20.4 for details */


Could you be more specific what section 2.20.4 is?

kasjer · 2024-10-22T06:34:56Z

If your first commit does not change functionality is it really needed?

andrzej-kaczmarek

Please don't move code around in .c files - this breaks git annotate

andrzej-kaczmarek · 2024-10-22T15:11:02Z

hw/mcu/dialog/da1469x/src/da1469x_clock.c

+da1469x_clock_lp_xtal32k_calibrate(void)
+{
+    g_mcu_clock_xtal32k_freq =
+        da1469x_clock_calibrate(2, MYNEWT_VAL(MCU_CLOCK_RCX_CAL_REF_CNT));


ref cnt should have separate syscfg

andrzej-kaczmarek · 2024-10-22T15:13:14Z

hw/mcu/dialog/da1469x/src/da1469x_lpclk.c

@@ -38,6 +38,7 @@ static void
 da1469x_lpclk_settle_tmr_cb(void *arg)
 {
    da1469x_clock_lp_xtal32k_switch();
+    da1469x_clock_lp_xtal32k_calibrate();


Calibration of XTAL32K should be optional and disabled by default - we should assume after settling it's accurate and has its native frequency.

I added the XTALK32K calib for full symmetry, but I see your point about making it optional & default off, to reduce latency.

andrzej-kaczmarek · 2024-10-22T15:16:31Z

hw/mcu/dialog/da1469x/src/da1469x_clock.c

 }

 void
 da1469x_clock_sys_rc32m_calibrate(void)
 {
-    g_mcu_clock_rc32m_freq = da1469x_clock_calibrate(1, 100);
+    g_mcu_clock_rc32m_freq = da1469x_clock_calibrate(DA1469X_CALIB_RC32M, RC32M_CAL_REF_CNT);


ref cnt should be configurable via syscfg for consistency

andrzej-kaczmarek · 2024-10-22T15:17:22Z

hw/mcu/dialog/da1469x/src/da1469x_clock.c

+#elif MYNEWT_VAL_CHOICE(MCU_LPCLK_SOURCE, RC32K)
+    da1469x_clock_lp_rc32k_calibrate();
+#elif MYNEWT_VAL_CHOICE(MCU_LPCLK_SOURCE, XTAL32K)
+    da1469x_clock_lp_xtal32k_calibrate();


as in other commit, this should be optional

andrzej-kaczmarek · 2024-10-22T15:20:00Z

hw/hal/include/hal/hal_os_tick.h

This code should be optional as it only applies to RCX. For devices which use XTAL32K and e.g. 128 OS ticks per seconds there's really no need to have extra overhead for ticks calculation.

I think a good way to handle this would be for the caller to either call hal_os_tick_calc_params() or not. (In other words, this API itself could be agnostic about which oscillator is being used - it just cares about the frequency.)

I added this comment to .h by mistake - it should apply to .c file (i.e. ticks calculation). Sorry for confusion.

apc067 · 2024-10-22T23:14:28Z

Please don't move code around in .c files - this breaks git annotate

Yeah, keeping the git annotate may indeed outweigh the benefits of having the functions in a neat order. To that extent, should I keep the "da1469x/clock: Eliminate magic numbers" commit, or should I leave those lines unchanged as well?

andrzej-kaczmarek · 2024-10-22T23:17:01Z

Please don't move code around in .c files - this breaks git annotate

Yeah, keeping the git annotate may indeed outweigh the benefits of having the functions in a neat order. To that extent, should I keep the "da1469x/clock: Eliminate magic numbers" commit, or should I leave those lines unchanged as well?

Keep it, removing magic numbers is fine.

This commit adds the missing services to the driver API. It also makes the actual calibration of the XTAL32K clock a syscfg option, defaulting to 0.

This commit replaces the magic numbers with meaningfully named constants.

This commit streamlines the LP clock API, by offering clean access to the LP clock selected via sysconfig.

This commit adds the function that calculates the RTC divider registers, and invokes it when the LP clock frequency changes.

If the LP clock's frequency is not an integer multiple of the specified OS tick frequency, the period of OS ticks will be incorrect due to an integer division truncation error (to the tune of almost 1% for RCX), resulting in OS Time gradually creeping away from the actual time. This commit fixes the issue, by maintaining the fractional OS tick value and advance OS Time accordingly.

vrahane · 2024-10-25T23:00:54Z

hw/mcu/dialog/da1469x/src/da1469x_clock.c

-    reg |= CRG_XTAL_XTALRDY_CTRL_REG_XTALRDY_CLK_SEL_Msk;
-    reg |= xtalrdy_cnt;
-    CRG_XTAL->XTALRDY_CTRL_REG = reg;
+    CRG_XTAL->XTALRDY_CTRL_REG = (xtalrdy_cnt << CRG_XTAL_XTALRDY_CTRL_REG_XTALRDY_CNT_Pos) |


nit-pick: nothing major, I think we should use the masks here specially because values are coming from a syscfg.

Good point; thanks!

This commit adds masking to register bitfields, where a wrong syscfg value may result in the inadvertent overrides of neighboring bitfields.

apc067 · 2024-10-26T00:36:04Z

Addressed all current reviewer comments.

github-actions bot added the size/l label Oct 17, 2024

apc067 force-pushed the peterc/DA1469x-clock-update branch from 9367986 to d85d3fc Compare October 18, 2024 22:26

kasjer reviewed Oct 21, 2024

View reviewed changes

kasjer requested a review from andrzej-kaczmarek October 21, 2024 07:28

apc067 force-pushed the peterc/DA1469x-clock-update branch from d85d3fc to 0d38224 Compare October 22, 2024 03:04

kasjer reviewed Oct 22, 2024

View reviewed changes

andrzej-kaczmarek requested changes Oct 22, 2024

View reviewed changes

apc067 added 5 commits October 25, 2024 12:21

da1469x/clock: Add missing services

4fd8c5f

This commit adds the missing services to the driver API. It also makes the actual calibration of the XTAL32K clock a syscfg option, defaulting to 0.

da1469x/clock: Eliminate magic numbers

095e850

This commit replaces the magic numbers with meaningfully named constants.

da1469x/clock: Streamline the LP clock API

1f314d8

This commit streamlines the LP clock API, by offering clean access to the LP clock selected via sysconfig.

da1469x/clock: Calculate the RTC dividers

e077c86

This commit adds the function that calculates the RTC divider registers, and invokes it when the LP clock frequency changes.

vrahane reviewed Oct 25, 2024

View reviewed changes

da1469x/clock: Protect register bitfields

561a02b

This commit adds masking to register bitfields, where a wrong syscfg value may result in the inadvertent overrides of neighboring bitfields.

apc067 force-pushed the peterc/DA1469x-clock-update branch from 0d38224 to 561a02b Compare October 26, 2024 00:28

github-actions bot added size/m and removed size/l labels Oct 26, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DA1469x: Clock time shifts on reboots #3321

DA1469x: Clock time shifts on reboots #3321

apc067 commented Oct 17, 2024

kasjer left a comment

kasjer Oct 21, 2024

apc067 Oct 22, 2024

kasjer Oct 22, 2024

apc067 Oct 22, 2024

andrzej-kaczmarek Oct 22, 2024

andrzej-kaczmarek Oct 22, 2024

apc067 commented Oct 22, 2024

kasjer Oct 22, 2024

apc067 Oct 22, 2024

kasjer commented Oct 22, 2024

andrzej-kaczmarek left a comment

andrzej-kaczmarek Oct 22, 2024 •

edited

Loading

andrzej-kaczmarek Oct 22, 2024

apc067 Oct 22, 2024 •

edited

Loading

andrzej-kaczmarek Oct 22, 2024

andrzej-kaczmarek Oct 22, 2024

andrzej-kaczmarek Oct 22, 2024

apc067 Oct 22, 2024

andrzej-kaczmarek Oct 22, 2024

apc067 commented Oct 22, 2024

andrzej-kaczmarek commented Oct 22, 2024

vrahane Oct 25, 2024

apc067 Oct 26, 2024

apc067 commented Oct 26, 2024

DA1469x: Clock time shifts on reboots #3321

Are you sure you want to change the base?

DA1469x: Clock time shifts on reboots #3321

Conversation

apc067 commented Oct 17, 2024

kasjer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apc067 commented Oct 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kasjer commented Oct 22, 2024

andrzej-kaczmarek left a comment

Choose a reason for hiding this comment

andrzej-kaczmarek Oct 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apc067 Oct 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apc067 commented Oct 22, 2024

andrzej-kaczmarek commented Oct 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apc067 commented Oct 26, 2024

andrzej-kaczmarek Oct 22, 2024 •

edited

Loading

apc067 Oct 22, 2024 •

edited

Loading