samples/mpu/mem_domain_apis_test: Did not get to "destroy app0 domain", went into indefinite loop

[cinlyooi-intel]

Describe the bug
According to sample.yaml, I am suppose to get console output "destroy app0 domain", instead, the test appears to go into indefinite loop

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=sam_e70_xplained
3. make
4. make run

Screenshots or console output

***** delaying boot 1000ms (per build configuration) *****
***** Booting Zephyr OS v1.14.0-rc3-104-g4aa48833d812 (delayed boot 1000ms) *****
initialize memory domains
add app thread 0 (0x204001e0) into app0_domain.
add app thread 1 (0x20400264) into app1_domain.
add app thread 2 (0x204002e8) into app0_domain.
main thread (0x20400500) yields.
app thread 0 (0x204001e0) starts.
app thread 0 (0x204001e0) yields.
app thread 1 (0x20400264) starts.
app thread 1 (0x20400264) yields.
app thread 2 (0x204002e8) starts.
app thread 2 (0x204002e8) yields.
main thread (0x20400500) is back.
main thread (0x20400500) yields.
app thread 0 (0x204001e0) is back.
app thread 0 (0x204001e0) yields.
app thread 1 (0x20400264) is back.
`***** delaying boot 1000ms (per build configuration) *****
***** Booting Zephyr OS v1.14.0-rc3-104-g4aa48833d812 (delayed boot 1000ms) *****
initialize memory domains
add app thread 0 (0x204001e0) into app0_domain.
add app thread 1 (0x20400264) into app1_domain.
add app thread 2 (0x204002e8) into app0_domain.
main thread (0x20400500) yields.
app thread 0 (0x204001e0) starts.
app thread 0 (0x204001e0) yields.
app thread 1 (0x20400264) starts.
app thread 1 (0x20400264) yields.
app thread 2 (0x204002e8) starts.
app thread 2 (0x204002e8) yields.
main thread (0x20400500) is back.
main thread (0x20400500) yields.
app thread 0 (0x204001e0) is back.
app thread 0 (0x204001e0) yields.
app thread 1 (0x20400264) is back.
***** delaying boot 1000ms (per build configuration) *****
***** Booting Zephyr OS v1.14.0-rc3-104-g4aa48833d812 (delayed boot 1000ms) *****
initialize memory domains
add app thread 0 (0x204001e0) into app0_domain.
add app thread 1 (0x20400264) into app1_domain.
add app thread 2 (0x204002e8) into app0_domain.
main thread (0x20400500) yields.
app thread 0 (0x204001e0) starts.
app thread 0 (0x204001e0) yields.
app thread 1 (0x20400264) starts.
app thread 1 (0x20400264) yields.
app thread 2 (0x204002e8) starts.
app thread 2 (0x204002e8) yields.
main thread (0x20400500) is back.
main thread (0x20400500) yields.
app thread 0 (0x204001e0) is back.
app thread 0 (0x204001e0) yields.
app thread 1 (0x20400264) is back.

Environment (please complete the following information):

• OS: fedora29
• Toolchain zephyr
• Commit SHA or Version used: 4aa4883

[andrewboie]

Another very old test. I'll look into it.

[ioannisg]

It looks, again, like a problem with the watch-dog IMHO

In addition to that, I agree, this test is old and needs re-work. To name a reason for that, the indicated log output does not correspond to the current MPU driver function calls, at least for ARM.

[ioannisg]

The sample runs in nrf52 boards, without problems.
When I set CONFIG_WDT_DISABLE_AT_BOOT=y, in prj.conf, the sample runs in sam_e70_xplained board and the output is identical to the output I get when i run on nRF52840_pca10056

[ioannisg]

Looking more into the sample, I realize that the actual logging from the MPU module is not printed in console, because the logging thread does not get chance to execute (all other threads have higher priorities and, simply, yield to each other).

I am submitting a patch to fix this

[andrewboie]

I think a better approach is to look at what scenarios this test is covering vs. what is being tested with ztest under tests/kernel/mem_protect, and if there is nothing unique, delete it.