TimerEvent tests #5046
TimerEvent tests #5046
Conversation
| virtual ~TestTimerEvent() { | ||
| } | ||
|
|
||
| void insert(timestamp_t ts) { |
There was a problem hiding this comment.
Why are we overriding the calls without changing anything? Can't we use them directly from TimerEvent?
There was a problem hiding this comment.
I needed them to be publicly accessible for test purposes. I've found a more elegant way to achieve that, so I'll update this code anyway.
| * Then @a ticker_queue is set properly | ||
| */ | ||
| template<typename T> | ||
| void test_ticker_queue(void) { |
There was a problem hiding this comment.
I would say this test goes to deep into the internals and tests other components. Problem with this approach is that internals can change and API should be stable. TimerEvent only calls Tickers API so I would only test it to this depth.
There was a problem hiding this comment.
Fixed -- after the update tests don't check any inernal structures.
| T tte; | ||
| tte.sem_wait(0); | ||
|
|
||
| tte.set_future_timestamp(TEST_DELAY_US); |
There was a problem hiding this comment.
maybe we could try that just after the call the semaphore is not incremented
| template<typename T> | ||
| void test_insert(void) { | ||
| T tte; | ||
| tte.sem_wait(0); |
There was a problem hiding this comment.
Why are we decrementing semaphore here? You can just initialise the semaphore with count of 0.
|
|
||
| tte.insert_absolute(tte.ticker_read_us() - 1ULL); | ||
| int32_t sem_slots = tte.sem_wait(0); | ||
| TEST_ASSERT_EQUAL(1, sem_slots); |
There was a problem hiding this comment.
Until #5051 is solved this assertion will fail on NUCLEO_F070RB & EFM32GG_STK3700.
fkjagodzinski
force-pushed
the
timerevent_tests
branch
from
3d650fd
to
89588cc
Compare
| Case("Test remove after insert_absolute", test_remove<TestTimerEventAbsolute>), | ||
|
|
||
| Case("Test insert zero", test_insert_zero<TestTimerEventRelative>), | ||
| Case("Test insert_absolute zero", test_insert_zero<TestTimerEventAbsolute>), |
There was a problem hiding this comment.
This test will fail on NUCLEO_F070RB and EFM32GG_STK3700 boards until #5051 is fixed.
| Case("Test insert_absolute zero", test_insert_zero<TestTimerEventAbsolute>), | ||
|
|
||
| Case("Test insert timestamp from the past", test_insert_past<TestTimerEventRelative>), | ||
| Case("Test insert_absolute timestamp from the past", test_insert_past<TestTimerEventAbsolute>), |
There was a problem hiding this comment.
This test will fail on NUCLEO_F070RB and EFM32GG_STK3700 boards until #5051 is fixed.
|
@fkjagodzinski @bulislaw What's the status of this? |
|
bump |
@theotherjimmy @0xc0170 @bulislaw |
|
Ready for CI -- preceding PR #5176 merged. |
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
|
/morph test-nightly |
Result: ABORTEDYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
|
Please look at failures, some of the new test cases fail |
|
Test case named which means the event handler was not called instantly after event insertion. @0xc0170 I could only check NRF51_DK and that seems to be a different case -- the handler is called eventually, but with a delay (~91 us) which looks more like #5159. To sum up, all failing boards don't comply with expected behaviour, which is: |
|
I looked at two devices, and could noticed some bugs in there. I can send a patch, but would like you to test them. I'll send a new PR shortly or can send you patch via email, you can ammend it here, to make tests pass. what do you think? |
|
@fkjagodzinski this commit fixes all failures in this PR - I dont have all devices with me now to retest, can you cherry-pick my commit here and we retest? These failures emphasize how important tests are ! |
fkjagodzinski
force-pushed
the
timerevent_tests
branch
from
89588cc
to
681de3e
Compare
|
Update:
|
|
Please ammend the last commit, NRF5 should have I removed timestamp from the equation, should not be there |
fkjagodzinski
force-pushed
the
timerevent_tests
branch
from
681de3e
to
6d9c782
Compare
|
@cmonr From what I know, @maciejbocianski is about to look into this issue. |
sleep_manager_racecondition test fix for devices with low CPU clock This RP contains fix for sleep_manager_racecondition test for very slow devices (like NRF51). It fixes the test itself as well as side effects of fix introduced in ARMmbed#5046 (us ticker: fix fire interrupt handling) The idea of the test was to test race condition between main thread and interrupt handler calling the same function. To efficiently test this, each handler call should interrupt main thread to make race more likely. On very slow devices (like NRF51) when we set very low ticker period (e.g less then 1000us for NRF51) there is no much time for thread scheduling. On such slow devices, setting period to 500 us cause that main thread is scheduled very rarely and only handler is constantly called making test unreliable. Fix introduced in ARMmbed#5046 (us ticker: fix fire interrupt handling) changed fire_interrupt function implementation causing more interrupt tailing thus even less time for main thread scheduling. After introduction of ARMmbed#5046 (us ticker: fix fire interrupt handling) when running sleep_manager_racecondition test on NRF51 (with ticker1.attach_us(&sleep_manager_locking_irq_test, 500);) test is failing with timeout due to the fact that interrupt handler is constantly called and main thread is never scheduled.
| @@ -74,11 +77,19 @@ void COMMON_RTC_IRQ_HANDLER(void) | |||
|
|
|||
| rtc_ovf_event_check(); | |||
|
|
|||
| if (m_common_sw_irq_flag & US_TICKER_SW_IRQ_MASK) { | |||
| m_common_sw_irq_flag &= ~US_TICKER_SW_IRQ_MASK; | |||
There was a problem hiding this comment.
looking at the codeflow, clear_interrupt is called right in the ticker_irq_handler, thus this could be moved there.
Do not follow this one flatten it to single if as it was before ?
There was a problem hiding this comment.
I meant single if like below. Single call of us_ticker_irq_handler will execute all outdated events
if ((m_common_sw_irq_flag & US_TICKER_SW_IRQ_MASK) || nrf_rtc_event_pending(COMMON_RTC_INSTANCE, US_TICKER_EVENT)) {
us_ticker_irq_handler();
}
Few targets need more than just pending IRQ set. They include some flags to be set that are checked in IRQ handler. This is the case for targets in this commit.
fkjagodzinski
force-pushed
the
timerevent_tests
branch
from
d006eaa
to
cd539e3
Compare
|
Update:
Local tests show all is ok now; fingers crossed for the CI tests to pass this time. :) |
|
/morph build |
Build : SUCCESSBuild number : 1230 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 899 |
Test : SUCCESSBuild number : 1031 |
sleep_manager_racecondition test fix for devices with low CPU clock This RP contains fix for sleep_manager_racecondition test for very slow devices (like NRF51). It fixes the test itself as well as side effects of fix introduced in #5046 (us ticker: fix fire interrupt handling) The idea of the test was to test race condition between main thread and interrupt handler calling the same function. To efficiently test this, each handler call should interrupt main thread to make race more likely. On very slow devices (like NRF51) when we set very low ticker period (e.g less then 1000us for NRF51) there is no much time for thread scheduling. On such slow devices, setting period to 500 us cause that main thread is scheduled very rarely and only handler is constantly called making test unreliable. Fix introduced in #5046 (us ticker: fix fire interrupt handling) changed fire_interrupt function implementation causing more interrupt tailing thus even less time for main thread scheduling. After introduction of #5046 (us ticker: fix fire interrupt handling) when running sleep_manager_racecondition test on NRF51 (with ticker1.attach_us(&sleep_manager_locking_irq_test, 500);) test is failing with timeout due to the fact that interrupt handler is constantly called and main thread is never scheduled.
sleep_manager_racecondition test fix for devices with low CPU clock This RP contains fix for sleep_manager_racecondition test for very slow devices (like NRF51). It fixes the test itself as well as side effects of fix introduced in #5046 (us ticker: fix fire interrupt handling) The idea of the test was to test race condition between main thread and interrupt handler calling the same function. To efficiently test this, each handler call should interrupt main thread to make race more likely. On very slow devices (like NRF51) when we set very low ticker period (e.g less then 1000us for NRF51) there is no much time for thread scheduling. On such slow devices, setting period to 500 us cause that main thread is scheduled very rarely and only handler is constantly called making test unreliable. Fix introduced in #5046 (us ticker: fix fire interrupt handling) changed fire_interrupt function implementation causing more interrupt tailing thus even less time for main thread scheduling. After introduction of #5046 (us ticker: fix fire interrupt handling) when running sleep_manager_racecondition test on NRF51 (with ticker1.attach_us(&sleep_manager_locking_irq_test, 500);) test is failing with timeout due to the fact that interrupt handler is constantly called and main thread is never scheduled.
Description
TimerEvent:Status
READY