It is possible that the difference between base and next tick count on some platforms is greater than 1, in this case we need to repeat counting with the reduced number of cycles (for slower boards).
If number of cycles has been reduced than base tick count needs to be redefined. This operation is missing and is added by this patch.
It has been noticed on NRF51_DK board that occurrence of system tick have impact on test execution.
NRF51_DK is a slow board with fast us ticker and handling of system tick interrupt takes about 250 us ticker ticks which have huge influence on interrupt tests where interrupt is set to <current count> + 100, 200, 500 ticks.
For NR51_DK US_TICKER_OV_LIMIT needs to be increased since if test is run few times in row sometimes fails. This is because NR51_DK is a slow board (16 MHz) with fast and short us ticker counter 1 MHz/16 bits.
Update the ticker common test to clean up after each case by restoring
the ticker IRQ handler. This allows tickers to function normally after
each case has completed.
- count_ticks: fix counter overflow handling,
- count_ticks: use reg_cycles variable in while loop,
- increment test: reduce number of cycles for slow cores if measure process needs to be repeated (difference is greater than 1).
On slow targets with fast high frequency tickers like NRF51_DK (16 Mhz CPU/1MHz ticker) time window for test case execution without overflow needs to be increased. Add parameter to `overflow_protect` function to be able to set different time window without overflow for us ticker and lp ticker.
Increment test proves that ticker counter is incremented by one.
This is done indirectly for high frequency counters where it is impossible to read 'value' and 'value + 1' in two successive ticker reads.
This check is done indirectly by counting ticker ticks elapsed during execution of N cycles of empty while loop. Unfortunately on slow boards with fast tickers like NRF51_DK(16 MHz CPU/1MHz hf ticker) it is possible that for the same N cycles measured number of elapsed ticks in two successive calls is greater than 1. This patch provides fix for such case - measure operation is repeated with the same number of cycles.
count_ticks() function counts ticker ticks elapsed during execution of N cycles of empty while loop.
In current version N value (cycles) is given as volatile paramater in order to disable possible compiler optimalisation.
There was a problem with measured time on different compilers and additionally results on ARM compiler were unexpected (the difference beetween measured elapsed ticks for the same number of cycles was to large). This might be caused by the memory access in order to store updated variable in memory. To fix this issue given numer of cycles has been stored into register and register is decremented (no memory access).
With this fix count_ticks(NUM_OF_CYCLES, 1) call returns 2500 +/-1 for us ticker ticks using each compiler (K64F).
On some platforms (e.g. K64F) different counters are used for time measurement and interrupt generation.
Because of that we should relax interrupt test case and give additional time before checking if interrupt handler has been executed.
Since according to the ticker requirements min acceptable counter size is 12 bits (low power timer) for which max count is 4095, then all test cases must be executed in this time window.
HAL ticker layer handles overflow and it is not handled in the target ticker drivers.
The intention was to use ticker_overflow_delta equal to 0 for low power ticker tests and ticker_overflow_delta equal to 50 for high frequency ticker tests. Current implementation is invalid since for devices which provide LOW_POWER_TIMER feature delta is equal to 0 and for devices without this feature delta is equal 50.
Since target specific ticker drivers are not ready also features which uses ticker in upper layers may not work correctly and tests for these features.
We need to disable also failing higher level ticker related tests (by adding check if DEVICE_USTICKER symbol is available and raise #error [NOT_SUPPORTED] if not).
The unified NRF51 target and feature BLE directories have been
reorganized to follow the naming and directory structure of the
NRF52 implementation.
This reorganization does not include TARGET_MCU_NRF51822 and
derived targets.
The flash clock test is disabled for the NRF52 series. This change
re-enables the test but with a higher tolerance to accommodate the
high jitter on the current ticker implementation.
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.
The current 0.1% clock tolerance is too small for certain platforms
which natural variance is larger than this. This commit increases the
tolerance to 0.5% instead.
Sample output from time_cpu_cycles called repeatedly in init,
before running any flash tests:
[1515706585.63][CONN][RXD] diff: 49316
[1515706585.69][CONN][RXD] diff: 49256
[1515706585.75][CONN][RXD] diff: 49286
[1515706585.81][CONN][RXD] diff: 49256
[1515706585.87][CONN][RXD] diff: 49225
[1515706585.94][CONN][RXD] diff: 49286
[1515706585.99][CONN][RXD] diff: 49317
[1515706586.06][CONN][RXD] diff: 49255
[1515706586.12][CONN][RXD] diff: 49286
[1515706586.18][CONN][RXD] diff: 49285
[1515706586.24][CONN][RXD] diff: 49286
[1515706586.31][CONN][RXD] diff: 49347
[1515706586.36][CONN][RXD] diff: 49347
[1515706586.43][CONN][RXD] diff: 49286
[1515706586.49][CONN][RXD] diff: 49286
[1515706586.55][CONN][RXD] diff: 49256
[1515706586.61][CONN][RXD] diff: 49286
[1515706586.68][CONN][RXD] diff: 49346
[1515706586.74][CONN][RXD] diff: 49347
[1515706586.80][CONN][RXD] diff: 49256
Notice the outliers will cause intermittent CI failures.
For each of the following years test example time of the first and last day of each month:
- first - 1970
- example not leap year (not divisible by 4)
- example leap year (divisible by 4 and by 100 and by 400)
- example leap year (divisible by 4 and not by 100)
- example not leap year (divisible by 4 and by 100)
- last fully supported - 2105
Test execution time on K64F is now ~39 sec.
Allow tickers to specify their native frequency and number of bits.
This allows the conversion to happen in common code rather than in
each vendor's implementation.
Remove the direct use of the microsecond and low power ticker from
the tests. This enforces that sleep mode is properly locked when
using timers. Furthermore, this prepares the codebase for new ticker
changes which allow differing clock frequencies and timer bit widths.
The lp_ticker test overrides the default ticker handler for the
low power ticker. This stops all other low power TimerEvents in the
system, including the ones for tickless, from getting called. Because
of this devices with tickless enabled malfunction during this test.
This patch fixes this problem by passing all lp ticker events it did
not trigger on to the TimerEvent irq handler.
This test exercises ticker API
- init should be executed just once
- read timestamp
Set interrupt should be tested via upper layer, as it does not provide
API to change handler that is invoked in the ISR ticker handler.
The test assumed that data written to flash would be memory mapped
and directly accessible. On some platform this is not the case
and data has to read back through an explicit read command.
The test has been changed to use the flash read command instead
of direct memory access.
2 test cases added, one for event in the past, one for event in future but very close
to the current time, thus once is set, it is already in the past, and we fire
interrupt immediately.
Initialize all values of timeinfo in make_time_info. This prevents
the field 'tm_isdst' from getting inadvertently set to 1 causing
time to be off by 1 hour.
The use of mktime was causing a fault when called in interrupt handler because on GCC it lock the mutex protecting the environment, To overcome this issue, this patch add dedicated routine to convert a time_t into a tm and vice versa.
In the process mktime has been optimized and is now an order of magnitude faster than the routines present in the C library.
This test was removed because of its memory footprint.
Most of the memory consummed by the test itself was related to the instantion of test cases in RAM.
With the introduction of case_t which allows tests cases to live in FLASH, the memory footprint has been drastically reduced (860 bytes of RAM saved) and the ticker test can be reintroduced in the code base.
This is temporary, as this test does not fit to some 16kB RAM devices. This requires few more steps: some small devices are using big async HAL structures, RTX changes increased the RAM footprint, plus this test seems to be too big. With all these, it won't fit in RAM regions for some devices.