lp_timeout test in TICKLESS mode #7328
Comments
|
ARM Internal Ref: MBOTRIAGE-924 |
|
Another question in sleep_lock driver test: |
|
Hi Jerome! Sorry missed that the first time round. sleep calls are allowed, but hopefully most of the people won't need them.
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:
|
|
@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. |
|
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. |
@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 ? |
|
@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. |
As suggested by Russ Butler in mbed-os issue ARMmbed#7328, and until there is an implementation of mbed-os issue ARMmbed#4408, we are implementing a workaround at HAL level to check if there is any ongoing serial transfer (which happens if HW FIFO is not yet empty). In case a transfer is ongoing, we're not entering deep sleep and return immediately.
As suggested by Russ Butler in mbed-os issue #7328, and until there is an implementation of mbed-os issue #4408, we are implementing a workaround at HAL level to check if there is any ongoing serial transfer (which happens if HW FIFO is not yet empty). In case a transfer is ongoing, we're not entering deep sleep and return immediately.
As suggested by Russ Butler in mbed-os issue #7328, and until there is an implementation of mbed-os issue #4408, we are implementing a workaround at HAL level to check if there is any ongoing serial transfer (which happens if HW FIFO is not yet empty). In case a transfer is ongoing, we're not entering deep sleep and return immediately.
As suggested by Russ Butler in mbed-os issue ARMmbed#7328, and until there is an implementation of mbed-os issue ARMmbed#4408, we are implementing a workaround at HAL level to check if there is any ongoing serial transfer (which happens if HW FIFO is not yet empty). In case a transfer is ongoing, we're not entering deep sleep and return immediately.
|
Hi all Check #7858, it seems that LPTICKER_DELAY_TICKS is still not fully compatible with TICKLESS ? |
|
Thx |
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
The text was updated successfully, but these errors were encountered: