Question: system_reset test delay and timeouts

[deepikabhavnani]

Description

Will like to know about DEFAULT_CYCLE_PERIOD https://github.com/ARMmbed/mbed-os/blob/master/TESTS/host_tests/system_reset.py#L20.

All of the host devices are expected to reset in 1 sec?
In case of Musca "TFM + mbed_boot" takes 3 sec and this might be the case with other ARMv8 devices supporting TFM as well.

We have forced_reset_timeout in targets.json, which is used by tools-host test. Shall we use the same for 'TESTS/host_tests/system_reset.py' ?

Issue request type

[] Question
[ ] Enhancement
[X] Bug

CC @gaborkertesz

[deepikabhavnani]

CC @ARMmbed/mbed-os-test @ARMmbed/mbed-os-hal
[Mirrored to Jira]

[fkjagodzinski]

All of the host devices are expected to reset in 1 sec?

@deepikabhavnani DEFAULT_CYCLE_PERIOD will be used only if given target does not define "program_cycle_s".

mbed-os/targets/targets.json

Line 1844 in 6addb89

"program_cycle_s": 2,

[Mirrored to Jira]

[deepikabhavnani]

Thanks @fkjagodzinski that will be useful.
Also, https://github.com/ARMmbed/mbed-os/blob/master/TESTS/mbed_platform/system_reset/main.cpp#L46 . Is this timeout "2" in addition to 'program_cycle_s / DEFAULT_CYCLE_PERIOD' or total test time.

Do we have documents describing program_cycle_s and forced_reset_timeout?
[Mirrored to Jira]

[gaborkertesz]

program_cycle_s

1. What is the definition of this attribute?
   The forced_reset_timeout is already set to 4, which means 4secs is set for startup timeout. Setting the same parameter for a test looks redundant for me and this probably changes other behavior I don't need to change.

2. I've just tested and adding "program_cycle_s": 4 to target.json doesn't change the delay between the reset and sync commands, while changing DEFAULT_CYCLE_PERIOD's value in the source code changes that. So either this json parameter is ignored or something is missing on my side.

3. Even if the cycle period is increased one or other way, the test default 2 secs timeout should be increased to "my timeout" + 2, otherwise the test will exit before the reset timeout is waited: https://github.com/ARMmbed/mbed-os/blob/master/TESTS/mbed_platform/system_reset/main.cpp#L46
   [Mirrored to Jira]

[0xc0170]

@ARMmbed/mbed-os-tools Please review
[Mirrored to Jira]

[cmonr]

@deepikabhavnani We do not have documentation on this, unless @bulislaw made some seperate from his original PR: #6230.

@gaborkertesz On #3, the config value might be getting overridden by this block of code: https://github.com/ARMmbed/mbed-os/blob/master/tools/targets/__init__.py#L305
I would suggest trying values other than 4 or 2 (something larger, maybe 5?) and see if anything changes.
[Mirrored to Jira]

[deepikabhavnani]

@AnotherButler @kegilbert - It will be good to document parameters like program_cycle_s and forced_reset_timeout which are added to aid testing but are part of targets.json
[Mirrored to Jira]

[gaborkertesz]

@ciarmcom My main concern is still that obviously program_cycle_s has a quite different purpose than waiting for system reset.
The simplified issue that the reset test is waiting some time for resetting the system and it's NOT equal to forced_reset_timeout. This forced_reset_timeout is used for waiting the system booting up before running tests, but only for the first bootup. So even if we can workaround that with program_cycle_s, I think reset test should wait for forced_reset_timeout.
[Mirrored to Jira]

[gaborkertesz]

@deepikabhavnani Can we change this issue from question to bug?
[Mirrored to Jira]