Fix for issue #10725 (tests-mbed_drivers-lp_timer failing nightly)

[mprse]

Summary of changes

tests-mbed_drivers-lp_timer is failing on UBLOX_C030_U201 (can't reproduce the failure locally).

According to the documentation of STM32F437VG76 MCU:

The LSI RC acts as an low-power clock source that can be kept running in Stop and
Standby mode for the independent watchdog (IWDG) and Auto-wakeup unit (AWU). The
clock frequency is around 32 kHz. For more details, refer to the electrical characteristics
section of the datasheets.

It seems that typical LSI frequency is 32 kHz, but it may vary from 17 to 47 kHz!
This means that lp-timer test may fail on the same board because lp-ticker frequency is unstable.

The proposition is to add ticker_update_freq() function and modify the test to perform lp-ticker calibration if the target uses LSI RC for lp-ticker.

Impact of changes

Migration actions required

Documentation

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[ciarmcom]

@mprse, thank you for your changes.
@ARMmbed/mbed-os-test @ARMmbed/mbed-os-core @ARMmbed/mbed-os-hal @ARMmbed/mbed-os-maintainers please review.

[adbridge]

@mprse could you please fill in the template correctly? Ie put your description etc under the right headings

[mprse]

@mprse could you please fill in the template correctly? Ie put your description etc under the right headings

Fixed.

[mprse]

@ARMmbed/mbed-os-hal Please review this fix for the failing lp-timer test.

More details and analysis can be found here: Issue #10725 (comment).
I'm not sure if this is the correct way of solving this problem. The proposition is to make an exception for STM boards that uses RTC/LSI for lp-ticker. With this PR for those targets, the lp-timer test makes an exception and calibrates lp-ticker frequency before the test.
I have doubts if this is the correct solution. It looks like the most proper way would be to disable li-ticker for these targets as they break the following requirement (unfortunately this will have an impact on many targets):

mbed-os/hal/us_ticker_api.h

Line 84 in 789a193

* * The ticker counts at the specified frequency +- 10% - Verified by ::ticker_frequency_test

[bulislaw]

That looks to me like fixing tests by changing the public API, which doesn't seem like a something we should be doing. Is this issue specific to tests? If not how users of the LP ticker will benefit?

[mprse]

@bulislaw

That looks to me like fixing tests by changing the public API

This is more like changing the public API to handle STM hardware limitation (LSI/RTC driven lp-ticker). On the same affected target lp-ticker frequency specified below can be different (and the one specified here is approximated):

mbed-os/targets/TARGET_STM/lp_ticker.c

Lines 516 to 523 in 5f495db

	const ticker_info_t *lp_ticker_get_info()
	{
	static const ticker_info_t info = {
	RTC_CLOCK / 4, // RTC_WAKEUPCLOCK_RTCCLK_DIV4
	32
	};
	return &info;
	}

Is this issue specific to tests?

It applies to all STM targets which are using RTC/LSI for lp-ticker. Please check detailed analysis: #10725 (comment)

If not how users of the LP ticker will benefit?

Currently, lp-ticker is inaccurate (sometimes more than assumed 10% tolerance) on affected targets. This is because according to the documentation typical LSI frequency is 32 kHz, but it may be in the range 17 kHz - 47 kHz (big discrepancy). The new API allows the user to calibrate and modify the lp-ticker frequency. This is also done in the failing test.

[bulislaw]

Currently, lp-ticker is inaccurate (sometimes more than assumed 10% tolerance) on affected targets. This is because according to the documentation typical LSI frequency is 32 kHz, but it may be in the range 17 kHz - 47 kHz (big discrepancy). The new API allows the user to calibrate and modify the lp-ticker frequency. This is also done in the failing test.

Should that be done in init?

@ARMmbed/team-st-mcd fyi

[mprse]

Should that be done in init?

I was thinking about this, but calibration takes at least one second. Alternatively, we can add a field like calibration_required to the ticker_info_t struct. This way the user will know that real ticker frequency can differ from the specified frequency. But since this issue only applies to some STM targets not sure if we should do this.

[0xc0170]

Disable lp-ticker for STM targets that use LSI. According to the requirements, lp-ticker accuracy should be +/- 10%. Since the test is failing this requirement is not met.

I would also do the calibration in the init (taking a note there it might take longer). Otherwise LSI is not ideal for lp ticker (breaking the requirements), thus disabling its use in lp ticker.

@ARMmbed/team-st-mcd Please review

[jeromecoutant]

Otherwise LSI is not ideal for lp ticker (breaking the requirements), thus disabling its use in lp ticker.

I agree, I think we could disable LP_TICKER when LSE is not available

[mprse]

Can I assume that the conclusion is that this PR should be closed and I should create a new PR that disables lp-ticker on STM devices which uses LSI to drive lp-ticker?

@jeromecoutant Is it an easy way to check for which devices lp-ticker should be disabled?

EDIT:
I assume that for the following targets lp-ticker should be disabled:

            "lpticker_lptim": {
                "help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
                "value": 0
            }

[jeromecoutant]

LSE and LPTICKER are enabled at STM32 FAMILY level,

so each time a target is disabling LSE:
"overrides": { "lse_available": 0 },

You should disable LPTICKER:
"device_has_remove": ["LPTICKER"],

[mprse]

@jeromecoutant One more question. What with boards that have:
"overrides": { "lse_available": 0 } and

"lpticker_lptim": {
                "help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
                "value": 1
            }

So LSE is not available, but lptim is used for lp-ticker. I believe in such case lp-ticker should not be disabled.

[mprse]

Created PR #12210 to solve this issue as we agreed (disable LP_TICKER when LSE is not available).

This PR will be closed.

[jeromecoutant]

OK

I think it could be a good patch if during init,
LSI real frequency value is calculated thanks to HSI.