tests/drivers/watchdog/wdt_basic_api/testcase.yaml: Various version of "Waiting to restart MCU" #13468
Assignees
Labels
area: Watchdog
Watchdog
bug
The issue is a bug, or the PR is fixing a bug
platform: Microchip SAM
Microchip SAM Platform (formerly Atmel SAM)
priority: low
Low impact/importance bug
Comments
nashif
added
area: Watchdog
|
On adruino duo : Commit ID 9072d34 |
|
Hi Cinlyooi, I checked this on my Nordic boards. It works fine with the latest version of Zephyr. BTW, why there is a The attachments are my screenshot. |
|
I also add 1000ms boot delay, and it works fine right. |
|
I am still working on understanding the test case execution. This is not a straight forward test cases like other unit test because we are expecting test_wdt() to be called repeatedly. My questions are: (0) I am expecting the at most 8 instances of "starting test - test_wdt", i.e. a pair for each for
As for the pair of instances: First one start the test, second one check the result. However, I am getting more that 8. Is that expected? (0.1) Will the test case automatically return, or I need to stop the test? (1) In both console output , I noted that you did not get this line: (2) Take the "with delay" test case: |
|
Observed in commit fd7c443 for nrf51_pca10028, nrf52_pca10040, nrf52840_pca10056 For nrf51_pca10028: for nrf52_pca10040: For nrf52840_pca10056 |
|
@overheat I am still a novice at zephyr. I think the problem is in I added a few TC_PRINT() statements to track the progress of the program and I believe the problem is in Based on my reading of the test case, this is what we should be seeing: (empty lines are mine) but we never got to Instead, we got into an infinite loop of Finally, please note that on quark_d2000_crb, test_wdt_callback_2 was disabled and the test passed. |
|
@cinlyooi-intel on which board it looping ? x86 quark_se_c1000 ? |
|
@cinlyooi-intel test_wdt_callback_2 . is specific to nrf boards. |
|
@SavinayDharmappa NRF boards that I have at Intel, i.e. pca10028, pca10040, and pca10056 |
|
I am not aware of nrf architecture ..some who has knowledge on NRF platform should look into it. |
|
@kl-cruz could you please take a look at this failing test? |
|
Ok, give me some time to reproduce it and dig into it |
|
Observed on an additional platform today, i.e. sam_e70_xplained (commit 6368ed4). Updated description |
|
Sorry for late, I am working on reviewing technical books, which bought almost ten years ago, for my job interview.
|
|
hi @overheat please take note that ,we observed similar issued on adruino_due board as well. |
|
@chiachuanwu |
|
@overheat m_testcase_index is variable which gets memory in noinit section. Default value of variable is not guaranteed to be zero on all platform. You patch assumes m_testcase_index default value will be zero.refer commit id 020884. So in your patch only second hunk is needed . |
|
Hi @overheat i had applied #14466 patch and tested on it, below was the result(2 board passed, 2 boards failed): Passed Boards: |
|
@chiachuanwu glad to know some boards work. Since I don't have sam_e70_xplained and arduino_due on my hand, I can not reproduce. I will try to find such Atmel MCU based board, and back later. |
|
@chiachuanwu I have received my arduino_due board and reproduced this failure on it. After a bit of digging, I believe it's related to ATSAMXX chip's watchdog driver because the watchdog callback function "wdt_int_cb0" didn't be invoked. So this failure on arduino_due or sam_e70_xplained is another issue rather than my previous patched one. @nashif Hi, do we have any Atmel chips (ATSAMXX ) expert here? Please notice he or she check this failure on arduino_due or sam_e70_xplained board. If not, I can keep digging on it but need a longer time. |
|
@overheat thanks for your update. |
|
Ok, I will take this and try to fix it today. |
|
@chiachuanwu Could do test this patch on sam_e70_xplained? It works on arduino_due, that I have tested. |
|
@overheat , i had tested PR#14968 , arduino_due board passed, but sam_e70_xplained board still failed, console log as below: arduino_due PASSED sam_e70_xplained (FAILED) |
|
@chiachuanwu Technically, this patch will repair all the boards based on ATMEL SAM3X, SAM4S and SAME70 chips. I will try to find a SAME70 board. |
galak
pushed a commit
that referenced
this issue
Mar 28, 2019
The original code cannot go to the next step on those boards enabled TEST_WDT_CALLBACK_2 macro, because of the flow control issue. So the test function cannot finish, and the board keeps restart. As a result, failure on the test. Fixes #13468 Signed-off-by: Aaron Tsui <aaron.tsui@outlook.com>
|
@cinlyooi-intel @chiachuanwu After digging deeper with GDB, I found that section .noinit be cleared during the boot process on ATSAME70, it's wrong according to line 422 in |
|
Sorry, still seeing the issue on master after #14466 is merged into it. Also see this when testing PR #14968 on its own os: fedora29 screenshot |
|
@cinlyooi-intel @SavinayDharmappa @chiachuanwu According to #15109, ATSAME70 don't preserve RAM when watchdog triggers, which is a kind of chip bug and also cause failure in watchdog test. So exclude this series of chips from this test. |
ioannisg
added
priority: low
|
This does not appear to be a generic test failure. I tested that it passes on all Nordic SOCs, 51, 52, 52840 and 9160 and frdm_k64f. It's a SAMe70 issue only. Most likely as @overheat suggested We still need to do something with the test, but since this is mostly related to the SAMe70 being peculiar, I 'm reducing the priority to low. Feel free to comment. |
overheat
added a commit
to overheat/zephyr
that referenced
this issue
Jul 1, 2019
ATSAM watchdog driver does not support callback which is not expected by the test. Update to make testing able to run on ATSAM watchdog drivers. ATSAME70 is NOT support this test, because the RAM is not preserved when the watchdog triggers. Fixes zephyrproject-rtos#13468 Signed-off-by: Aaron Tsui <aaron.tsui@outlook.com>
ioannisg
added
the
platform: Microchip SAM
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Various versions of "Waiting to restart MCU" exists. Unlike #12803 and #13417, this sets of results does not have the "Watchdog setup error" line.
The key here is, we see the test stuck at "Waiting to restart MCU" line. or after
***** delaying boot 1000ms (per build configuration) *****
***** Booting Zephyr OS v1.14.0-rc1-248-gd5b2834f58 (delayed boot 1000ms) *****
which follow the "Wait to restart MCU" line.
At times, we see the test cases keep repeating itself.
In all cases, at the end, test did not return properly.
We will see this when it is running "test_wdt_no_callback" or "test_wdt_callback_1" or or "test_wdt_callback_2" test cases.
Will be using this bug to store all failure cases at "Watchdog setup error"
To Reproduce
Steps to reproduce the behavior:
Screenshots or console output
Please note that any platform can exhibit the console logs recorded here. The boards listed are for reference to real instance:
Observed on nrf51_pca10028:
Observed on nrf52_pca10040:
Observed on nrf52840_pca10056:
[Update 20190313] Observed on sam_e70_xplained: Commit ID: 6368ed4
[Update 20190313] Observed on arduino_due: Commit ID: 6368ed4
Environment (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: