-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nightly: CY8CPROTO_062_4343W target failed at sleep/deep sleep test #12434
Comments
cc @ARMmbed/team-cypress |
Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2548 |
Increasing the sleep time fixed an issue where some tests were failing when Greentea was run with a 9600 baudrate. See the issue here: #11909 |
After investigating this I've found a couple different causes for the sleep test failures. The specific case that is failing is the deepsleep_lpticker_test(): Our low-level (psoc6pdl) UART driver prevents the system from entering deep sleep if there is any data in the UART RX or TX FIFOs (initially we assumed this was the hardware itself preventing deep sleep but that does not appear so). During the deepsleep test, just before entering deep sleep, it turns out there is data on both the RX and TX FIFOs. The data in the TX FIFO comes from the GT messages being sent at the end of the for loop in deepsleep_ticker_test(). This can be fixed by simply moving the busy_wait_ms(SERIAL_FLUSH_TIME_MS) call into the for loop instead of above it. The data in the RX FIFO was harder to track down. The data consists of a single byte in the FIFO: a '\n'. This '\n' was sent by GT as part of the __sync kv packet during test initialization. It was not being read off the FIFO because of a bug in the DUT side greentea client: specifically HandleKV() in greentea_test_env.cpp. HandleKV() reads up to the final "}}" and returns success but does not read the final '\n'. This does not cause an error otherwise because the greentea-client code ignores whitespace coming in across the UART. Note: According to https://github.com/ARMmbed/mbed-os-tools/blob/master/src/mbed_os_tools/test/host_tests_conn_proxy/conn_primitive.py#L39 all kv pairs are sent with a terminating '\n'. The fix for this (I'll put in a PR soon) is to add a line that reads that final '\n' in the HandleKV code. Once issue 1 was cleared up I ran into another issue: The board would successfully enter deep sleep but consistently took 100ms too long to wake up. The root cause here is a delay in our SDHC deepsleep wake up code. The delay was added to allow time for clock stabilization. A proper resolution to this issue is being discussed but simply removing the delay fixes the deepsleep issue. So ultimately 3 things need to happen to close this issue:
|
@dustin-crossman Nice findings! Will wait for the fixes |
@0xc0170 That's just an autolink issue. #s 1, 2, and 3 refer to the issues from my comment above: #12434 (comment) Also to update: Issue 3 is being worked on right now. |
This is fixed |
Description of defect
Sleep test are failing on CY8CPROTO_062_4343W.
It looks that it fail to enter deep sleep due to uart.
I thought it was already fixed by introducing uart flush wait time ?
mbed-os/TESTS/mbed_hal/sleep/sleep_test_utils.h
Lines 32 to 45 in bac5ffe
@dustin-crossman
Does the issue described here (#11792 (comment)) was already fixed?
Target(s) affected by this defect ?
CY8CPROTO_062_4343W
Toolchain(s) (name and version) displaying this defect ?
all
What version of Mbed-os are you using (tag or sha) ?
latest master
69a7d67
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
mbed-cli 1.10.2
mbed-cloud-sdk 2.0.8
mbed-flasher 0.10.1
mbed-greentea 1.7.4
mbed-host-tests 1.5.10
mbed-ls 1.7.10
mbed-os-tools 0.0.9
How is this defect reproduced ?
mbed test -t GCC_ARM -m CY8CPROTO_062_4343W -n tests-mbed_hal-sleep -v
The text was updated successfully, but these errors were encountered: