Silabs EFM32 watchdog timeout values

[fkjagodzinski]

Description

@scartmell-arm @donatieng I checked our watchdog tests locally and found that some of them fail on EFM32GG_STK3700. Here is the test summary:

+-------------------------+-----------------+-----------------------------------+----------------------------------------+--------+--------+---------+--------------------+
| target                  | platform_name   | test suite                        | test case                              | passed | failed | result  | elapsed_time (sec) |
+-------------------------+-----------------+-----------------------------------+----------------------------------------+--------+--------+---------+--------------------+
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-reset_reason   | tests-mbed_drivers-reset_reason        | 1      | 0      | OK      | 32.72              |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog       | Restart multiple times                 | 0      | 1      | FAIL    | 0.02               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog       | Start, 0 ms                            | 0      | 0      | SKIPPED | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog       | Start, 500 ms                          | 0      | 0      | SKIPPED | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog       | Start, max_timeout                     | 0      | 0      | SKIPPED | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog       | Start, max_timeout exceeded            | 0      | 0      | SKIPPED | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog       | Stop                                   | 1      | 0      | OK      | 0.52               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog       | max_timeout is valid                   | 1      | 0      | OK      | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog_reset | Kicking the watchdog prevents reset    | 1      | 0      | OK      | 0.03               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog_reset | Watchdog reset                         | 1      | 0      | OK      | 0.01               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog_reset | Watchdog reset in sleep mode           | 1      | 0      | OK      | 0.01               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_drivers-watchdog_reset | Watchdog started again                 | 1      | 0      | OK      | 0.02               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-reset_reason       | tests-mbed_hal-reset_reason            | 1      | 0      | OK      | 32.56              |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog           | Init, 500 ms                           | 0      | 0      | SKIPPED | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog           | Init, max_timeout                      | 0      | 0      | SKIPPED | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog           | Platform feature max_timeout is valid  | 1      | 0      | OK      | 0.01               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog           | Stopped watchdog can be started again  | 1      | 0      | OK      | 0.01               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog           | Update config with multiple init calls | 0      | 1      | FAIL    | 0.01               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog           | Watchdog can be stopped                | 1      | 0      | OK      | 0.52               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_reset     | Kicking the watchdog prevents reset    | 1      | 0      | OK      | 0.01               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_reset     | Watchdog reset                         | 1      | 0      | OK      | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_reset     | Watchdog reset in sleep mode           | 1      | 0      | OK      | 0.02               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_reset     | Watchdog started again                 | 1      | 0      | OK      | 0.01               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_timing    | Timing, 1000 ms                        | 1      | 0      | OK      | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_timing    | Timing, 200 ms                         | 1      | 0      | OK      | 0.0                |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_timing    | Timing, 3000 ms                        | 0      | 1      | FAIL    | 0.02               |
| EFM32GG_STK3700-GCC_ARM | EFM32GG_STK3700 | tests-mbed_hal-watchdog_timing    | Timing, 500 ms                         | 1      | 0      | OK      | 0.0                |
+-------------------------+-----------------+-----------------------------------+----------------------------------------+--------+--------+---------+--------------------+

This is because EFM32 targets have a list of predefined watchdog timeouts that may be set.

mbed-os/targets/TARGET_Silicon_Labs/TARGET_EFM32/emlib/inc/em_wdog.h

Lines 66 to 84 in 7995e8b

	/** Watchdog period selection. */
	typedef enum {
	wdogPeriod_9 = 0x0, /**< 9 clock periods */
	wdogPeriod_17 = 0x1, /**< 17 clock periods */
	wdogPeriod_33 = 0x2, /**< 33 clock periods */
	wdogPeriod_65 = 0x3, /**< 65 clock periods */
	wdogPeriod_129 = 0x4, /**< 129 clock periods */
	wdogPeriod_257 = 0x5, /**< 257 clock periods */
	wdogPeriod_513 = 0x6, /**< 513 clock periods */
	wdogPeriod_1k = 0x7, /**< 1025 clock periods */
	wdogPeriod_2k = 0x8, /**< 2049 clock periods */
	wdogPeriod_4k = 0x9, /**< 4097 clock periods */
	wdogPeriod_8k = 0xA, /**< 8193 clock periods */
	wdogPeriod_16k = 0xB, /**< 16385 clock periods */
	wdogPeriod_32k = 0xC, /**< 32769 clock periods */
	wdogPeriod_64k = 0xD, /**< 65537 clock periods */
	wdogPeriod_128k = 0xE, /**< 131073 clock periods */
	wdogPeriod_256k = 0xF /**< 262145 clock periods */
	} WDOG_PeriodSel_TypeDef;

Assuming we use the default wdogClkSelULFRCO 1 kHz clock, an arbitrary value like 500 ms cannot be set (the closest we can get is 513 ms in this case).

So the question is: Should we provide some additional info to the user? Or maybe explicitly state that the timeout value actually set in the peripheral may be far from the parameter value used in hal_watchdog_init() call?

We could also point to the hal_watchdog_get_reload_value() fun, that can be used to verify the timeout setting.

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug

[0xc0170]

@ARMmbed/team-silabs Please review

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-210

[fkjagodzinski]

@c1728p9, @rajkan01, I'm curious what's your opinion on this. Would a warning note in the docs be enough in this case?

[c1728p9]

The HAL spec for watchdog states:

The timeout must be accurate to the nearest millisecond.

This seems a bit strict. Do any of our use cases this much accuracy? Maybe this requirement could be relaxed to something like +-50% of the target value? @scartmell-arm what are your thoughts?

[donatieng]

Requiring one millisecond accuracy is unrealistic on most targets as oscillators used for watchdog peripherals are often imprecise (and they don't need to be).

I think we should change this requirement to something like:

• The watchdog should trigger at or after the timeout value
• The watchdog should trigger before twice the timeout value

@c1728p9 @fkjagodzinski @rajkan01 @scartmell-arm thoughts?

[c1728p9]

Sounds good to me.

[stevew817]

From the ARMmbed/team-silabs perspective I support the proposal from @donatieng

[stevew817]

@c1728p9 @donatieng Was this issue followed up on? Can we drive towards closure?

[donatieng]

Apologies for the late reply, I'm following up with @rajkan01 to make sure this is reflected within #10066

[rajkan01]

Needs to specify watchdog timeout value in targets.json file based on target on the new implementation
"hw-watchdog_timeout": {
"help": "Define the timeout in ms value LowPowerTicker to do HW kick",
"value": "800",
"macro_name": "HW_WATCHDOG_TIMEOUT"
}
Here value 800/2 configured as hardware watchdog timeout,i will update watchdog.md file once the PR#10066 merged into feature-watchdog branch.

@fkjagodzinski I thing we need to configure this value before running watchdog test in the hardware...Please check

[fkjagodzinski]

@fkjagodzinski I thing we need to configure this value before running watchdog test in the hardware...Please check

@rajkan01 Yes, the HW_WATCHDOG_TIMEOUT parameter is used in tests that come with the new implementation of the driver/platform layer.

mbed-os/TESTS/mbed_platform/watchdog_mgr_reset/main.cpp

Line 90 in fdc1be5

wait((HW_WATCHDOG_TIMEOUT + TIMEOUT_DELTA_MS) / 1000.0); // Device reset expected.