Mbed-os: lp_timeout test in TICKLESS mode

Created on 26 Jun 2018  路  17Comments  路  Source: ARMmbed/mbed-os

Description

Hi

In TICKLESS mode, I got 2 questions in TESTS/mbed_drivers/timeout/timeout_tests.h

  • is direct call to sleep() function still allowed ?

  • there are some wait_ms() call function to allow hardware serial buffers to completely flush.
    But maybe these call should be protected by sleep_manager_lock_deep_sleep() ?

Thx

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug

CLOSED drivers mirrored

Most helpful comment

Hi @LMESTM the issue of going to sleep while there is a byte in the HW serial buffer has not been fixed. I'll make sure this gets fixed as part of the HAL specification for uarts.

Another question in sleep_lock driver test:
is it relevant to check this deepsleep lock status in TICKLESS mode as it seems that systimer is constantly called ?

This is still relevant, but the test is broken at the moment, as LPTICKER_DELAY_TICKS makes use of the microsecond ticker which locks deep sleep at different points in time. @0xc0170 you added this test right? Do you have any suggestions on how to work around this? What are your thoughts on sleeping for a second or two and reading the time in deep sleep? This may be a good indication of if deep sleep and the sleep lock are working.

All 17 comments

ARM Internal Ref: MBOTRIAGE-924

Another question in sleep_lock driver test:
is it relevant to check this deepsleep lock status in TICKLESS mode as it seems that systimer is constantly called ?

It seems that issues appear when LPTICKER_DELAY_TICKS is set...

@bulislaw @c1728p9

@ashok-rao @screamerbg

Hi Jerome! Sorry missed that the first time round. sleep calls are allowed, but hopefully most of the people won't need them.

there are some wait_ms() call function to allow hardware serial buffers to completely flush.
But maybe these call should be protected by sleep_manager_lock_deep_sleep() ?

Serial is protected with deep sleep locks anyway, so as long as transfer is in progress that shouldn't be necessary: https://github.com/ARMmbed/mbed-os/blob/master/drivers/SerialBase.cpp

@c1728p9 could you have a look at:

Another question in sleep_lock driver test:
is it relevant to check this deepsleep lock status in TICKLESS mode as it seems that systimer is constantly called ?

It seems that issues appear when LPTICKER_DELAY_TICKS is set...

@bulislaw I think that deep sleep protection applies only up to the serial putc to be empty, but I am not sure that it will check for HW serial buffer to be really complete.
See Initial concern raised 2 years back #1849
Other issues where same issue was raised according to @bridadan : #3132 #2966
Request for enhancement #4408 1 year old
Current workaround: #3017 => this adds a wait to let HW buffer enough time to empty ... except with tickless wait() will actually proceed with deep sleep entry ...
But maybe I missed a fix somewhere and #4408 should be closed ... just let me know.

Hi @LMESTM the issue of going to sleep while there is a byte in the HW serial buffer has not been fixed. I'll make sure this gets fixed as part of the HAL specification for uarts.

Another question in sleep_lock driver test:
is it relevant to check this deepsleep lock status in TICKLESS mode as it seems that systimer is constantly called ?

This is still relevant, but the test is broken at the moment, as LPTICKER_DELAY_TICKS makes use of the microsecond ticker which locks deep sleep at different points in time. @0xc0170 you added this test right? Do you have any suggestions on how to work around this? What are your thoughts on sleeping for a second or two and reading the time in deep sleep? This may be a good indication of if deep sleep and the sleep lock are working.

Another question in sleep_lock driver test:
is it relevant to check this deepsleep lock status in TICKLESS mode as it seems that systimer is constantly called ?

@jeromecoutant Can you reference the file and lines for this.

https://github.com/ARMmbed/mbed-os/blob/58fa28b9b21cf0d361ee2e615d6d7fb850b0c205/TESTS/mbed_drivers/sleep_lock/main.cpp#L32

If a ticker is on going due to LPTICKER_DELAY_TICKS, tests starts in a wrong state

@c1728p9 any update about LPTICKER_DELAY_TICKS in TICKLESS mode ?

@bulislaw any update about wait protection for deepsleep ?

@bulislaw @c1728p9 Bump

@jeromecoutant I created a PR #7524 to fix some of the problems of LPTICKER_DELAY_TICKS and TICKLESS. It doesn't fix the dropped UART bytes from entering deep sleep though. That problem will need to be fixed by a serial HAL specification or maybe even a high-priority change directly to master.

Hi all

Check #7858, it seems that LPTICKER_DELAY_TICKS is still not fully compatible with TICKLESS ?

@c1728p9 @bulislaw please see question above.

Thx

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  4Comments

DuyTrandeLion picture DuyTrandeLion  路  3Comments

pilotak picture pilotak  路  3Comments

bcostm picture bcostm  路  4Comments

bcostm picture bcostm  路  4Comments