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
[x] Question
[ ] Enhancement
[ ] Bug
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.
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
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.
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.