xtimer: weird behavior of tests/xtimer_drift, bug? #5103

haukepetersen · 2016-03-18T09:51:30Z

I am not sure if this is a bug in the xtimer, the xtimer_drift test but it is very likely. I got this broken behavior when running the xtimer_drift test on nrf51 base boards (e.g. airfy-beacon, nrf51dongle):

2016-03-18 10:36:51,856 - INFO # now=15.397038 (0 hours 0 min), diff=0
2016-03-18 10:36:52,861 - INFO # now=16.397038 (0 hours 0 min), diff=0
2016-03-18 10:36:53,856 - INFO # now=17.397038 (0 hours 0 min), diff=0 // so far good
2016-03-18 10:37:28,411 - INFO # now=18.397038 (0 hours 0 min), diff=0 // jump of 35 sec
2016-03-18 10:37:46,190 - INFO # now=19.397038 (0 hours 0 min), diff=0 // jump of 18 sec
2016-03-18 10:37:47,190 - INFO # now=20.397038 (0 hours 0 min), diff=0
2016-03-18 10:37:48,190 - INFO # now=21.397038 (0 hours 0 min), diff=0
2016-03-18 10:37:49,190 - INFO # now=22.397038 (0 hours 0 min), diff=0
2016-03-18 10:37:50,191 - INFO # now=23.397038 (0 hours 0 min), diff=0
2016-03-18 10:38:07,966 - INFO # now=24.397038 (0 hours 0 min), diff=0 // jump of 17 sec
2016-03-18 10:38:08,966 - INFO # now=25.397038 (0 hours 0 min), diff=0

or

2016-03-18 10:49:04,860 - INFO # now=102.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:05,860 - INFO # now=103.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:23,637 - INFO # now=104.098898 (0 hours 1 min), diff=0 // jump
2016-03-18 10:49:24,637 - INFO # now=105.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:25,637 - INFO # now=106.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:26,637 - INFO # now=107.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:27,637 - INFO # now=108.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:28,637 - INFO # now=109.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:29,637 - INFO # now=110.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:47,414 - INFO # now=111.098898 (0 hours 1 min), diff=0 // jump
2016-03-18 10:49:48,414 - INFO # now=112.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:49,414 - INFO # now=113.098898 (0 hours 1 min), diff=0
2016-03-18 10:49:50,414 - INFO # now=114.098898 (0 hours 1 min), diff=0

Those jumps appear on random intervals.

I am ~90% convinced, that this is not caused by the peripheral timer driver, as the exact code is also running on the nrf52dk, where this behavior does not appear. It rather seems to me, that the xtimer (or the test app) has some concurrency issue, which shows only at the clock speed of the nrf51 boards (16MHz), but not at the higher speed of the nrf52 board.

I actually found this when debugging the timer for the cc26x0 (#4675), where the test shows also very strange behavior...

The text was updated successfully, but these errors were encountered:

haukepetersen · 2016-03-18T10:45:01Z

Just out of interest, I have been running this test on the same CPUs:

#define TIM_SPEED           (1000000ul) /* try to run with 1MHz */

#define STEP                (10000U)
#define SUM                 (500)

static volatile int busy = 1;
static volatile int count = 0;

static void cb(void *arg, int chan)
{
    ++count;
    if (count == SUM) {
        count = 0;
        busy = 0;
    }

    timer_set(TIMER_DEV(0), 0, STEP);
}

int main(void)
{
    timer_init(TIMER_DEV(0), TIM_SPEED, cb, NULL);
    timer_set(TIMER_DEV(0), 0, STEP);

    while (1) {
        while (busy) {}
        busy = 1;
        puts("PING");
    }

    return 0;
}

With this, I get the PING message printed out reliable every 5s, for about half an hour now, without any pings skipped. So the issues seems only to appear when actually multiplexing timers?!

jnohlgard · 2016-03-18T12:53:01Z

I guess a missed deadline. Try increasing XTIMER_BACKOFF and XTIMER_OVERHEAD (or whatever the constants in xtimer.h are called, I'm too lazy to look them up right now)

haukepetersen · 2016-03-18T15:41:17Z

already played with XTIMER_SHIFT_ON_COMPARE, same behavior for different values...

haukepetersen · 2016-03-18T15:42:47Z

same for XTIMER_BACKOFF

jnohlgard · 2016-03-18T16:02:37Z

@haukepetersen is that the platform with 16 MHz timer fixed frequency?

what values did you test?

kaspar030 · 2016-03-20T22:37:32Z

@haukepetersen Is the underlying timer 32bit wide?

haukepetersen · 2016-03-21T09:53:43Z

EDIT:
24-bit timer with a system clock of 16MHz

haukepetersen · 2016-03-21T09:54:23Z

xtimer config is:

#define XTIMER                      (0)
#define XTIMER_CHAN                 (0)
#define XTIMER_MASK                 (0xff000000)
#define XTIMER_SHIFT_ON_COMPARE     (2)
#define XTIMER_BACKOFF              (40)

haukepetersen · 2016-03-21T09:56:10Z

and the (well functioning) nrf52dk runs at 48MHz with a 32-bit timer configuration (with xtimer default config).

jnohlgard · 2016-03-21T09:59:54Z

The mask is wrong
On Mar 21, 2016 10:54 AM, "Hauke Petersen" notifications@github.com wrote:

xtimer config is:

#define XTIMER (0)
#define XTIMER_CHAN (0)
#define XTIMER_MASK (0xff000000)
#define XTIMER_SHIFT_ON_COMPARE (2)
#define XTIMER_BACKOFF (40)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#5103 (comment)

haukepetersen · 2016-03-21T15:33:24Z

you mean it should be 0xffffff00?

How about we spend some more documentation on the xtimer configuration values? And possibly put them into one easy to find block in the xtimer.h?

kaspar030 · 2016-03-21T15:34:15Z

you mean it should be 0xffffff00?

No, he answered before you edited your post stating the timer was 16bit.

kaspar030 · 2016-03-21T15:35:47Z

How about we spend some more documentation on the xtimer configuration values? And possibly put them into one easy to find block in the xtimer.h?

Not enough:
https://github.com/RIOT-OS/RIOT/blob/master/sys/include/xtimer.h#L369
?

haukepetersen · 2016-03-21T15:37:50Z

actually it is enough. But it might be a good idea to move it (together with the other configuration options) to the top of the file, so it can easily be located?!

kaspar030 · 2016-03-21T15:38:27Z

Not the way we've been doing it...

http://doc.riot-os.org/group__sys__xtimer.html ?

kaspar030 · 2016-03-21T15:39:14Z

I'd love to help. How can I get one of the affected boards?

haukepetersen · 2016-03-21T15:53:40Z

quote 'who ever looks at the f**ing doxygen' :-) But I guess you are right, that should be sufficient...

Back to this issue, so far I saw this behavior on the 'airfy-beacon' and 'nrf51dongle', and as stated not on the nrf52dk. Also I saw similar (or maybe different, but strange) behavior on the cc2650stk -> #4675

RIOT-2016.10 - Release Notes ============================ RIOT is a real-time multi-threading operating system that supports a range of devices that are typically found in the Internet of Things: 8-bit microcontrollers, 16-bit microcontrollers and light-weight 32-bit processors. RIOT is based on the following design principles: energy-efficiency, real-time capabilities, small memory footprint, modularity, and uniform API access, independent of the underlying hardware (this API offers partial POSIX compliance). RIOT is developed by an international open source community which is independent of specific vendors (e.g. similarly to the Linux community) and is licensed with a non-viral copyleft license (LGPLv2.1), which allows indirect business models around the free open-source software platform provided by RIOT. About this release: =================== This release provides a lot of new features as well as it fixes several major bugs. Among these new features are the new simplified network socket API called sock, the GNRC specific CoAP implementation gcoap and several new packages: TinyDTLS, the Aversive++ microcontroller library for robotics, the u8g2 graphic library, and nanocoap. Using the new sock API an implementation of the Simple Time Network Protocol (SNTP) was also introduced, allowing for time synchronization between nodes. New platforms include the Arduino Uno, the Arduino Duemilanove, the Arduino Zero, SODAQ Autonomo, and the Zolertia remote (rev. B). The most significant bug fix was done in native which led to a significantly more robust handling of ISRs and now allows for at least 1,000 native instances running stably on one machine. About 263 pull requests with about 398 commits have been merged since the last release and about 42 issues have been solved. 37 people contributed with code in 100 days. 1006 files have been touched with 166500 insertions and 26926 deletions. Notations used below: ===================== + means new feature/item * means modified feature/item - means removed feature/item New features and changes ======================== General ------- * Verbose behavior for assert() macro Core ---- + MPU support for Cortex-M API changes ----------- + Socket-like sock API (replacing conn) * netdev2: Add Testmodes and CCA modes * IEEE 802.15.4: clean-up Intra-PAN behavior * IEEE 802.15.4: centralize default values * gnrc_pktbuf: allow for 0-sized snips + gnrc_netapi: mbox and arbitrary callback support System libraries ---------------- No new features or changes Networking ---------- + Provide sock-port for GNRC + gcoap: a GNRC-based CoAP implementation + Simple Network Time Protocol (RFC 5905, section 14) + Priority Queue for packet snips + IPv4 header definitions Packages -------- + nanocoap: CoAP header parser/builder + TinyDTLS: DTLS library + tiny-asn1: asn.1/der decoder + Aversive++ microcontroller programming library + u8g2 graphic library Platforms --------- + Support for stm32f2xx MCU family + Low power modes for samd21 CPUs + More Arduino-based platforms: + Arduino Uno + Arduino Duemilanove + Arduino Zero + More boards of ST's Nucleo platforms: + ST Nucleo F030 board support + ST Nucleo F070 board support + ST Nucleo F446 board support + SODAQ Automono + Zolertia remote rev. B Drivers ------- + W5100 Ethernet device + Atmel IO1 Xplained extension + LPD8808 LED strips * at86rf2xx: provide capability to access the RND_VALUE random value register Build System ------------ + static-tests build target for easy local execution of CI's static tests Other ----- + Provide Arduino API to Nucleo boards + Packer configuration file to build vagrant boxes + CC2650STK Debugger Support + ethos: add Ethos over TCP support Fixed Issues from the last release ================================== #534: native debugging on osx fails #2071: native: *long* overdue fixes #3341: netdev2_tap crashes when hammered #5007: gnrc icmpv6: Ping reply goes out the wrong interface #5432: native: valgrind fails Known Issues ============ Networking related issues ------------------------- #3075: nhdp: unnecessary microsecond precision: NHDP works with timer values of microsecond precision which is not required. Changing to lower precision would save some memory. #4048: potential racey memory leak: According to the packet buffer stats, flood-pinging a multicast destination may lead to a memory leak due to a race condition. However, it seems to be a rare case and a completely filled up packet buffer was not observed. #4388: POSIX sockets: open socket is bound to a specific thread: This was an inherit problem of the conn API under GNRC. Since the POSIX sockets are still based on conn for this release, this issue persists #4527: gnrc_ipv6: Multicast is not forwarded if routing node listens to the address (might still be fixable for release, see #5729, #5230: gnrc ipv6: multicast packets are not dispatched to the upper layers) #5016: gnrc_rpl: Rejoining RPL instance as root after reboot messes up routing #5055: cpuid: multiple radios will get same EUI-64 Nodes with multiple interfaces might get the same EUI-64 for them since they are generated from the same CPU ID. #5656: Possible Weakness with locking in the GNRC network stack: For some operations mutexes to the network interfaces need to get unlocked in the current implementation to not get deadlocked. Recursive mutexes as provided in #5731 might help to solve this problem. #5748: gnrc: nodes crashing with too small packet buffer: A packet buffer of size ~512 B might lead to crashes. The issue describes this for several hundret nodes, but agressive flooding with just two nodes was also shown to lead to this problem. #5858: gnrc: 6lo: potential problem with reassembly of fragments: If one frame gets lost the reassembly state machine might get out of sync ### NDP is not working properly #4499: handle of l2src_len in gnrc_ndp_rtr_sol_handle: Reception of a router solicitation might lead to invalid zero-length link-layer addresses in neighbor cache. #5005: ndp: router advertisement sent with global address: Under some circumstances a router might send RAs with GUAs. While they are ignored on receive (as RFC 4861 specifies), RAs should have link-local addresses and not even be send out this way. #5122: NDP: global unicast address on non-6LBR nodes disappears after a while: Several issues (also see #5760) lead to a global unicast address effectively being banned from the network (disappears from neighbor cache, is not added again) #5467: ipv6 address vanishes when ARO (wrongly) indicates DUP caused by outdated ncache at router #5539: Border Router: packet not forwarded from ethos to interface 6 #5790: ND: Lost of Global IPV6 on node after sending lot of UDP frame from BR Timer related issues -------------------- #4841: xtimer: timer already in the list: Under some conditions an xtimer can end up twice in the internal list of the xtimer module #4902: xtimer: xtimer_set: xtimer_set does not handle integer overflows well #5338: xtimer: xtimer_now() not ISR safe for non-32-bit platforms. #5928: xtimer: usage in board_init() crashes: some boards use the xtimer in there board_init() function. The xtimer is however first initialized in the auto_init module which is executed after board_init() #6052: tests: xtimer_drift gets stuck: xtimer_drift application freezes after ~30-200 seconds native related issues --------------------- #495: native not float safe: When the FPU is used when an asynchronous context switch occurs, either the stack gets corrupted or a floating point exception occurs. #2175: ubjson: valgind registers "Invalid write of size 4" in unittests #4590: pkg: building relic with clang fails. #5796: native: tlsf: early malloc will lead to a crash: TLSF needs pools to be initialized (which is currently expected to be done in an application). If a malloc is needed before an application's main started (e.g. driver initialization) the node can crash, since no pool is allocated yet. other platform related issues ----------------------------- #1891: newlib-nano: Printf formatting does not work properly for some numberic types: PRI[uxdi]64, PRI[uxdi]8 and float are not parsed in newlib-nano #2006: cpu/nrf51822: timer callback may be fired too early #2143: unittests: tests-core doesn't compile for all platforms: GCC build-ins were used in the unittests which are not available with msp430-gcc #2300: qemu unittest fails because of a page fault #4512: pkg: tests: RELIC unittests fail on iotlab-m3 #4522: avsextrem: linker sometimes doesn't find `bl_init_clks()` #4560: make: clang is more pedantic than gcc oonf_api is not building with clang. (Partly solved by #4593) #4694: drivers/lm75a: does not build #4737: cortex-m: Hard fault after a thread exits (under some circumstances) #4822: kw2xrf: packet loss when packets get fragmented #4876: at86rf2xx: Simultaneous use of different transceiver types is not supported #4954: chronos: compiling with -O0 breaks #4866: not all GPIO driver implementations are thread safe: Due to non-atomic operations in the drivers some pin configurations might get lost. #5009: RIOT is saw-toothing in energy consumption (even when idling) #5103: xtimer: weird behavior of tests/xtimer_drift: xtimer_drift randomly jumps a few seconds on nrf52 #5361: cpu/cc26x0: timer broken #5405: Eratic timings on iotlab-m3 with compression context activated #5460: cpu/samd21: i2c timing with compiler optimization #5486: at86rf2xx: lost interrupts #5489: cpu/lpc11u34: ADC broken #5603: atmega boards second UART issue #5678: at86rf2xx: failed assertion in _isr #5719: cc2538: rf driver doesn't handle large packets #5799: kw2x: 15.4 duplicate transmits #5944: msp430: ipv6_hdr unittests fail #5848: arduino: Race condition in sys/arduino/Makefile.include #5954: nRF52 uart_write get stuck #6018: nRF52 gnrc 6lowpan ble memory leak other issues ------------ #1263: TLSF implementation contains (a) read-before-write error(s). #3256: make: Setting constants on compile time doesn't really set them everywhere #3366: periph/i2c: handle NACK #4488: Making the newlib thread-safe: When calling puts/printf after thread_create(), the CPU hangs for DMA enabled uart drivers. #4866: periph: GPIO drivers are not thread safe #5128: make: buildtest breaks when exporting FEATURES_PROVIDED var #5207: make: buildest fails with board dependent application Makefiles #5390: pkg: OpenWSN does not compile: This package still uses deprecated modules and was not tested for a long time. #5520: tests/periph_uart not working #5561: C++11 extensions in header files #5776: make: Predefining CFLAGS are parsed weirdly #5863: OSX + SAMR21-xpro: shell cannot handle command inputs larger than 64 chars #5962: Makefile: UNDEF variable is not working as documented #6022: pkg: build order issue Special Thanks ============== We like to give our special thanks to all the companies that provided us with their hardware for porting and testing, namely the people from (in alphabeticalorder): Atmel, Freescale, Imagination Technologies, Limifrog, Nordic, OpenMote, Phytec, SiLabs, UDOO,and Zolertia; and also companies that directly sponsored development time: Cisco Systems, Eistec, Ell-i, Enigeering Spirit, Nordic, FreshTemp LLC, OTAkeys and Phytec. More information ================ http://www.riot-os.org Mailing lists ------------- * RIOT OS kernel developers list devel@riot-os.org (http://lists.riot-os.org/mailman/listinfo/devel) * RIOT OS users list users@riot-os.org (http://lists.riot-os.org/mailman/listinfo/users) * RIOT commits commits@riot-os.org (http://lists.riot-os.org/mailman/listinfo/commits) * Github notifications notifications@riot-os.org (http://lists.riot-os.org/mailman/listinfo/notifications) IRC --- * Join the RIOT IRC channel at: irc.freenode.net, #riot-os License ======= * Most of the code developed by the RIOT community is licensed under the GNU Lesser General Public License (LGPL) version 2.1 as published by the Free Software Foundation. * Some external sources are published under a separate, LGPL compatible license (e.g. some files developed by SICS). All code files contain licensing information.

RIOT-2016.10 - Release Notes ============================ RIOT is a real-time multi-threading operating system that supports a range of devices that are typically found in the Internet of Things: 8-bit microcontrollers, 16-bit microcontrollers and light-weight 32-bit processors. RIOT is based on the following design principles: energy-efficiency, real-time capabilities, small memory footprint, modularity, and uniform API access, independent of the underlying hardware (this API offers partial POSIX compliance). RIOT is developed by an international open source community which is independent of specific vendors (e.g. similarly to the Linux community) and is licensed with a non-viral copyleft license (LGPLv2.1), which allows indirect business models around the free open-source software platform provided by RIOT. About this release: =================== This release provides a lot of new features as well as it fixes several major bugs. Among these new features are the new simplified network socket API called sock, the GNRC specific CoAP implementation gcoap and several new packages: TinyDTLS, the Aversive++ microcontroller library for robotics, the u8g2 graphic library, and nanocoap. Using the new sock API an implementation of the Simple Time Network Protocol (SNTP) was also introduced, allowing for time synchronization between nodes. New platforms include the Arduino Uno, the Arduino Duemilanove, the Arduino Zero, SODAQ Autonomo, and the Zolertia remote (rev. B). The most significant bug fix was done in native which led to a significantly more robust handling of ISRs and now allows for at least 1,000 native instances running stably on one machine. About 263 pull requests with about 398 commits have been merged since the last release and about 42 issues have been solved. 37 people contributed with code in 100 days. 1006 files have been touched with 166500 insertions and 26926 deletions. Notations used below: ===================== + means new feature/item * means modified feature/item - means removed feature/item New features and changes ======================== General ------- * Verbose behavior for assert() macro Core ---- + MPU support for Cortex-M API changes ----------- + Socket-like sock API (replacing conn) * netdev2: Add Testmodes and CCA modes * IEEE 802.15.4: clean-up Intra-PAN behavior * IEEE 802.15.4: centralize default values * gnrc_pktbuf: allow for 0-sized snips + gnrc_netapi: mbox and arbitrary callback support System libraries ---------------- No new features or changes Networking ---------- + Provide sock-port for GNRC + gcoap: a GNRC-based CoAP implementation + Simple Network Time Protocol (RFC 5905, section 14) + Priority Queue for packet snips + IPv4 header definitions Packages -------- + nanocoap: CoAP header parser/builder + TinyDTLS: DTLS library + tiny-asn1: asn.1/der decoder + Aversive++ microcontroller programming library + u8g2 graphic library Platforms --------- + Support for stm32f2xx MCU family + Low power modes for samd21 CPUs + More Arduino-based platforms: + Arduino Uno + Arduino Duemilanove + Arduino Zero + More boards of ST's Nucleo platforms: + ST Nucleo F030 board support + ST Nucleo F070 board support + ST Nucleo F446 board support + SODAQ Automono + Zolertia remote rev. B Drivers ------- + W5100 Ethernet device + Atmel IO1 Xplained extension + LPD8808 LED strips * at86rf2xx: provide capability to access the RND_VALUE random value register Build System ------------ + static-tests build target for easy local execution of CI's static tests Other ----- + Provide Arduino API to Nucleo boards + Packer configuration file to build vagrant boxes + CC2650STK Debugger Support + ethos: add Ethos over TCP support Fixed Issues from the last release ================================== RIOT-OS#534: native debugging on osx fails RIOT-OS#2071: native: *long* overdue fixes RIOT-OS#3341: netdev2_tap crashes when hammered RIOT-OS#5007: gnrc icmpv6: Ping reply goes out the wrong interface RIOT-OS#5432: native: valgrind fails Known Issues ============ Networking related issues ------------------------- RIOT-OS#3075: nhdp: unnecessary microsecond precision: NHDP works with timer values of microsecond precision which is not required. Changing to lower precision would save some memory. RIOT-OS#4048: potential racey memory leak: According to the packet buffer stats, flood-pinging a multicast destination may lead to a memory leak due to a race condition. However, it seems to be a rare case and a completely filled up packet buffer was not observed. RIOT-OS#4388: POSIX sockets: open socket is bound to a specific thread: This was an inherit problem of the conn API under GNRC. Since the POSIX sockets are still based on conn for this release, this issue persists RIOT-OS#4527: gnrc_ipv6: Multicast is not forwarded if routing node listens to the address (might still be fixable for release, see RIOT-OS#5729, RIOT-OS#5230: gnrc ipv6: multicast packets are not dispatched to the upper layers) RIOT-OS#5016: gnrc_rpl: Rejoining RPL instance as root after reboot messes up routing RIOT-OS#5055: cpuid: multiple radios will get same EUI-64 Nodes with multiple interfaces might get the same EUI-64 for them since they are generated from the same CPU ID. RIOT-OS#5656: Possible Weakness with locking in the GNRC network stack: For some operations mutexes to the network interfaces need to get unlocked in the current implementation to not get deadlocked. Recursive mutexes as provided in RIOT-OS#5731 might help to solve this problem. RIOT-OS#5748: gnrc: nodes crashing with too small packet buffer: A packet buffer of size ~512 B might lead to crashes. The issue describes this for several hundret nodes, but agressive flooding with just two nodes was also shown to lead to this problem. RIOT-OS#5858: gnrc: 6lo: potential problem with reassembly of fragments: If one frame gets lost the reassembly state machine might get out of sync ### NDP is not working properly RIOT-OS#4499: handle of l2src_len in gnrc_ndp_rtr_sol_handle: Reception of a router solicitation might lead to invalid zero-length link-layer addresses in neighbor cache. RIOT-OS#5005: ndp: router advertisement sent with global address: Under some circumstances a router might send RAs with GUAs. While they are ignored on receive (as RFC 4861 specifies), RAs should have link-local addresses and not even be send out this way. RIOT-OS#5122: NDP: global unicast address on non-6LBR nodes disappears after a while: Several issues (also see RIOT-OS#5760) lead to a global unicast address effectively being banned from the network (disappears from neighbor cache, is not added again) RIOT-OS#5467: ipv6 address vanishes when ARO (wrongly) indicates DUP caused by outdated ncache at router RIOT-OS#5539: Border Router: packet not forwarded from ethos to interface 6 RIOT-OS#5790: ND: Lost of Global IPV6 on node after sending lot of UDP frame from BR Timer related issues -------------------- RIOT-OS#4841: xtimer: timer already in the list: Under some conditions an xtimer can end up twice in the internal list of the xtimer module RIOT-OS#4902: xtimer: xtimer_set: xtimer_set does not handle integer overflows well RIOT-OS#5338: xtimer: xtimer_now() not ISR safe for non-32-bit platforms. RIOT-OS#5928: xtimer: usage in board_init() crashes: some boards use the xtimer in there board_init() function. The xtimer is however first initialized in the auto_init module which is executed after board_init() RIOT-OS#6052: tests: xtimer_drift gets stuck: xtimer_drift application freezes after ~30-200 seconds native related issues --------------------- RIOT-OS#495: native not float safe: When the FPU is used when an asynchronous context switch occurs, either the stack gets corrupted or a floating point exception occurs. RIOT-OS#2175: ubjson: valgind registers "Invalid write of size 4" in unittests RIOT-OS#4590: pkg: building relic with clang fails. RIOT-OS#5796: native: tlsf: early malloc will lead to a crash: TLSF needs pools to be initialized (which is currently expected to be done in an application). If a malloc is needed before an application's main started (e.g. driver initialization) the node can crash, since no pool is allocated yet. other platform related issues ----------------------------- RIOT-OS#1891: newlib-nano: Printf formatting does not work properly for some numberic types: PRI[uxdi]64, PRI[uxdi]8 and float are not parsed in newlib-nano RIOT-OS#2006: cpu/nrf51822: timer callback may be fired too early RIOT-OS#2143: unittests: tests-core doesn't compile for all platforms: GCC build-ins were used in the unittests which are not available with msp430-gcc RIOT-OS#2300: qemu unittest fails because of a page fault RIOT-OS#4512: pkg: tests: RELIC unittests fail on iotlab-m3 RIOT-OS#4522: avsextrem: linker sometimes doesn't find `bl_init_clks()` RIOT-OS#4560: make: clang is more pedantic than gcc oonf_api is not building with clang. (Partly solved by RIOT-OS#4593) RIOT-OS#4694: drivers/lm75a: does not build RIOT-OS#4737: cortex-m: Hard fault after a thread exits (under some circumstances) RIOT-OS#4822: kw2xrf: packet loss when packets get fragmented RIOT-OS#4876: at86rf2xx: Simultaneous use of different transceiver types is not supported RIOT-OS#4954: chronos: compiling with -O0 breaks RIOT-OS#4866: not all GPIO driver implementations are thread safe: Due to non-atomic operations in the drivers some pin configurations might get lost. RIOT-OS#5009: RIOT is saw-toothing in energy consumption (even when idling) RIOT-OS#5103: xtimer: weird behavior of tests/xtimer_drift: xtimer_drift randomly jumps a few seconds on nrf52 RIOT-OS#5361: cpu/cc26x0: timer broken RIOT-OS#5405: Eratic timings on iotlab-m3 with compression context activated RIOT-OS#5460: cpu/samd21: i2c timing with compiler optimization RIOT-OS#5486: at86rf2xx: lost interrupts RIOT-OS#5489: cpu/lpc11u34: ADC broken RIOT-OS#5603: atmega boards second UART issue RIOT-OS#5678: at86rf2xx: failed assertion in _isr RIOT-OS#5719: cc2538: rf driver doesn't handle large packets RIOT-OS#5799: kw2x: 15.4 duplicate transmits RIOT-OS#5944: msp430: ipv6_hdr unittests fail RIOT-OS#5848: arduino: Race condition in sys/arduino/Makefile.include RIOT-OS#5954: nRF52 uart_write get stuck RIOT-OS#6018: nRF52 gnrc 6lowpan ble memory leak other issues ------------ RIOT-OS#1263: TLSF implementation contains (a) read-before-write error(s). RIOT-OS#3256: make: Setting constants on compile time doesn't really set them everywhere RIOT-OS#3366: periph/i2c: handle NACK RIOT-OS#4488: Making the newlib thread-safe: When calling puts/printf after thread_create(), the CPU hangs for DMA enabled uart drivers. RIOT-OS#4866: periph: GPIO drivers are not thread safe RIOT-OS#5128: make: buildtest breaks when exporting FEATURES_PROVIDED var RIOT-OS#5207: make: buildest fails with board dependent application Makefiles RIOT-OS#5390: pkg: OpenWSN does not compile: This package still uses deprecated modules and was not tested for a long time. RIOT-OS#5520: tests/periph_uart not working RIOT-OS#5561: C++11 extensions in header files RIOT-OS#5776: make: Predefining CFLAGS are parsed weirdly RIOT-OS#5863: OSX + SAMR21-xpro: shell cannot handle command inputs larger than 64 chars RIOT-OS#5962: Makefile: UNDEF variable is not working as documented RIOT-OS#6022: pkg: build order issue Special Thanks ============== We like to give our special thanks to all the companies that provided us with their hardware for porting and testing, namely the people from (in alphabeticalorder): Atmel, Freescale, Imagination Technologies, Limifrog, Nordic, OpenMote, Phytec, SiLabs, UDOO,and Zolertia; and also companies that directly sponsored development time: Cisco Systems, Eistec, Ell-i, Enigeering Spirit, Nordic, FreshTemp LLC, OTAkeys and Phytec. More information ================ http://www.riot-os.org Mailing lists ------------- * RIOT OS kernel developers list devel@riot-os.org (http://lists.riot-os.org/mailman/listinfo/devel) * RIOT OS users list users@riot-os.org (http://lists.riot-os.org/mailman/listinfo/users) * RIOT commits commits@riot-os.org (http://lists.riot-os.org/mailman/listinfo/commits) * Github notifications notifications@riot-os.org (http://lists.riot-os.org/mailman/listinfo/notifications) IRC --- * Join the RIOT IRC channel at: irc.freenode.net, #riot-os License ======= * Most of the code developed by the RIOT community is licensed under the GNU Lesser General Public License (LGPL) version 2.1 as published by the Free Software Foundation. * Some external sources are published under a separate, LGPL compatible license (e.g. some files developed by SICS). All code files contain licensing information.

PeterKietzmann · 2017-01-26T15:42:33Z

@haukepetersen @kaspar030 does this issue still persist???

haukepetersen · 2017-08-28T13:23:55Z

Just checked, the issue at hand does still exist.

smlng · 2017-08-30T19:50:02Z

cannot confirm behaviour on cc2650stk, I created a gist with the output of tests/xtimer_drift over the first 1000s. The only curious thing is that instead of having 1s between each output it falls short by roughly 6ms (994ms instead of 1000ms) between each print out. As the low level periph timer is running at 1MHz it cannot be some rounding offset but might rather be related to some of the internal offset when setting a timer.

kYc0o · 2018-07-17T13:47:23Z

@Josar is this handled by one of your xtimer PRs?

Josar · 2018-07-17T18:42:29Z

Why is there no test for this? So it can be run from command line?

Every line has errors in the log of a run on jiminy.
Riot/master

2018-07-17 20:26:31,381 - INFO # now=1.044784 (0x0001fe26 ticks), drift=680 us, jitter=680 us
2018-07-17 20:26:33,955 - INFO # now=2.044368 (0x0003e63a ticks), drift=264 us, jitter=-416 us
2018-07-17 20:26:36,525 - INFO # now=3.043912 (0x0005ce49 ticks), drift=-192 us, jitter=-456 us
2018-07-17 20:26:38,569 - INFO # now=4.043848 (0x0007b689 ticks), drift=-256 us, jitter=-64 us
2018-07-17 20:26:40,618 - INFO # now=5.043784 (0x00099ec9 ticks), drift=-320 us, jitter=-64 us
2018-07-17 20:26:42,665 - INFO # now=6.043720 (0x000b8709 ticks), drift=-384 us, jitter=-64 us
2018-07-17 20:26:44,188 - INFO # now=7.044400 (0x000d6fa6 ticks), drift=296 us, jitter=680 us
2018-07-17 20:26:47,284 - INFO # now=8.043592 (0x000f5789 ticks), drift=-512 us, jitter=-808 us
2018-07-17 20:26:49,329 - INFO # now=9.044272 (0x00114026 ticks), drift=168 us, jitter=680 us
2018-07-17 20:26:51,901 - INFO # now=10.044000 (0x0013284c ticks), drift=-104 us, jitter=-272 us
2018-07-17 20:26:55,518 - INFO # now=11.043552 (0x0015105c ticks), drift=-552 us, jitter=-448 us
2018-07-17 20:26:57,565 - INFO # now=12.043336 (0x0016f889 ticks), drift=-768 us, jitter=-216 us
2018-07-17 20:27:01,705 - INFO # now=13.043272 (0x0018e0c9 ticks), drift=-832 us, jitter=-64 us
2018-07-17 20:27:04,801 - INFO # now=14.043632 (0x001ac93e ticks), drift=-472 us, jitter=360 us
2018-07-17 20:27:08,420 - INFO # now=15.043144 (0x001cb149 ticks), drift=-960 us, jitter=-488 us
2018-07-17 20:27:09,943 - INFO # now=16.043080 (0x001e9989 ticks), drift=-1024 us, jitter=-64 us
2018-07-17 20:27:13,036 - INFO # now=17.044224 (0x00208260 ticks), drift=120 us, jitter=1144 us
2018-07-17 20:27:14,036 - INFO # now=18.043728 (0x00226a6a ticks), drift=-376 us, jitter=-496 us
2018-07-17 20:27:16,082 - INFO # now=19.042888 (0x00245249 ticks), drift=-1216 us, jitter=-840 us
2018-07-17 20:27:20,224 - INFO # now=20.042824 (0x00263a89 ticks), drift=-1280 us, jitter=-64 us
2018-07-17 20:27:22,270 - INFO # now=21.042760 (0x002822c9 ticks), drift=-1344 us, jitter=-64 us
2018-07-17 20:27:25,364 - INFO # now=22.043504 (0x002a0b6e ticks), drift=-600 us, jitter=744 us
2018-07-17 20:27:27,935 - INFO # now=23.043256 (0x002bf397 ticks), drift=-848 us, jitter=-248 us
2018-07-17 20:27:29,457 - INFO # now=24.042568 (0x002ddb89 ticks), drift=-1536 us, jitter=-688 us
2018-07-17 20:27:31,505 - INFO # now=25.042504 (0x002fc3c9 ticks), drift=-1600 us, jitter=-64 us
2018-07-17 20:27:34,598 - INFO # now=26.042440 (0x0031ac09 ticks), drift=-1664 us, jitter=-64 us
2018-07-17 20:27:36,121 - INFO # now=27.042376 (0x00339449 ticks), drift=-1728 us, jitter=-64 us
2018-07-17 20:27:38,349 - INFO # now=28.042312 (0x00357c89 ticks), drift=-1792 us, jitter=-64 us
2018-07-17 20:27:41,445 - INFO # now=29.042712 (0x00376503 ticks), drift=-1392 us, jitter=400 us
2018-07-17 20:27:44,015 - INFO # now=30.042184 (0x00394d09 ticks), drift=-1920 us, jitter=-528 us
2018-07-17 20:27:46,585 - INFO # now=31.042120 (0x003b3549 ticks), drift=-1984 us, jitter=-64 us
2018-07-17 20:27:48,632 - INFO # now=32.042056 (0x003d1d89 ticks), drift=-2048 us, jitter=-64 us
2018-07-17 20:27:50,680 - INFO # now=33.041992 (0x003f05c9 ticks), drift=-2112 us, jitter=-64 us
2018-07-17 20:27:53,251 - INFO # now=34.041928 (0x0040ee09 ticks), drift=-2176 us, jitter=-64 us

Maybe adding a test to xtimer_drift which checks if the timer is triggered every second, would be a good idea.

Running a test with #9211 which is a bit longer shows an error. Im still investigating. It results in an run condition.

2018-07-17 20:36:32,257 - INFO # now=46.044016 (0x0057d26e ticks), drift=-2944 us, jitter=-56 us
2018-07-17 20:36:33,256 - INFO # now=47.043952 (0x0059baae ticks), drift=-3008 us, jitter=-64 us
2018-07-17 20:36:34,256 - INFO # now=48.044504 (0x005ba33b ticks), drift=-2456 us, jitter=552 us
2018-07-17 20:36:35,253 - INFO # now=49.043824 (0x005d8b2e ticks), drift=-3136 us, jitter=-680 us
2018-07-17 20:36:36,252 - INFO # now=50.044376 (0x005f73bb ticks), drift=-2584 us, jitter=552 us
2018-07-17 20:36:37,067 - INFO # now=50.857280 (0x006100a8 ticks), drift=-189680 us, jitter=-187096 us
Invalid time between messages, expected 0.9 < 0.8036865524291992 < 1.1
2018-07-17 20:36:37,109 - INFO # now=50.898240 (0x006114a8 ticks), drift=-1148720 us, jitter=-959040 us
Invalid time between messages, expected 0.9 < 0.043022871017456055 < 1.1
2018-07-17 20:36:37,149 - INFO # now=50.940304 (0x00612936 ticks), drift=-2106656 us, jitter=-957936 us
Invalid time between messages, expected 0.9 < 0.0441131591796875 < 1.1
2018-07-17 20:36:37,192 - INFO # now=50.984488 (0x00613ec5 ticks), drift=-3062472 us, jitter=-955816 us
Invalid time between messages, expected 0.9 < 0.037940025369589844 < 1.1
2018-07-17 20:36:37,237 - INFO # now=51.026528 (0x0061534c ticks), drift=-4020436 us, jitter=-957960 us
Invalid time between messages, expected 0.9 < 0.048392534255981445 < 1.1
2018-07-17 20:36:37,278 - INFO # now=51.069128 (0x00616819 ticks), drift=-4977836 us, jitter=-957400 us
Invalid time between messages, expected 0.9 < 0.037430763644628906 < 1.1
2018-07-17 20:36:37,319 - INFO # now=51.110920 (0x00617c81 ticks), drift=-5936040 us, jitter=-958208 us
Invalid time between messages, expected 0.9 < 0.04099702835083008 < 1.1
2018-07-17 20:36:37,363 - INFO # now=51.153504 (0x0061914c ticks), drift=-6893456 us, jitter=-957416 us
Invalid time between messages, expected 0.9 < 0.04384756088256836 < 1.1
2018-07-17 20:36:37,404 - INFO # now=51.194536 (0x0061a555 ticks), drift=-7852424 us, jitter=-958968 us
Invalid time between messages, expected 0.9 < 0.04053783416748047 < 1.1
2018-07-17 20:36:37,447 - INFO # now=51.238920 (0x0061bb01 ticks), drift=-8808040 us, jitter=-955616 us
Invalid time between messages, expected 0.9 < 0.04381418228149414 < 1.1
2018-07-17 20:36:37,491 - INFO # now=51.280984 (0x0061cf8b ticks), drift=-9765976 us, jitter=-957936 us
Invalid time between messages, expected 0.9 < 0.04336380958557129 < 1.1
2018-07-17 20:36:37,536 - INFO # now=51.362720 (0x0061e3ec ticks), drift=-10724240 us, jitter=-958264 us

Seems to be related to timer close to an overflow.

Josar · 2018-07-18T10:02:09Z

@kYc0o the problem with the race condition is because of the high working load. This lead to a always to late target in _xtimer_periodic_wakeup. This can be fixed, but then it does not behave like described.

IMHO, its a bad idea to not update the last_wakeup if the set target is allready reached as this could lead to a allways late target depending on the period.

Josar · 2018-07-18T12:09:20Z

@kYc0o please see #9595 #9596

kYc0o · 2018-07-18T12:22:49Z

Thank you @Josar !

stale · 2019-09-21T15:33:10Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

MichelRottleuthner · 2020-01-24T16:57:57Z

Was fixed with #9530 as can be seen from the testing results in the comments there.
I also checked with nrf51dk again and there are no more random delays/jumps in tests/xtimer_drift.

haukepetersen added the Area: timers Area: timer subsystems label Mar 18, 2016

haukepetersen assigned kaspar030 Mar 18, 2016

haukepetersen mentioned this issue Mar 21, 2016

board-support: cc2650stk #4675

Merged

miri64 added this to the Release 2016.10 milestone Oct 18, 2016

miri64 mentioned this issue Nov 3, 2016

tests: xtimer_drift gets stuck on native #6052

Closed

miri64 modified the milestones: Release 2016.10, Release 2017.01 Nov 11, 2016

PeterKietzmann modified the milestones: Release 2017.01, Release 2017.04 Jan 26, 2017

This was referenced May 31, 2017

xtimer: add's items to the wrong list if the timer overflows between _xtimer_now() and irq_disable() #7114

Closed

sys/xtimer: Fix possible race condition in xtimer where sleep is added to the wrong list. #7116

Closed

aabadie modified the milestones: Release 2017.04, Release 2017.07 Jun 21, 2017

kYc0o added the Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) label Oct 31, 2017

Josar mentioned this issue Jul 18, 2018

tests/xtimer_drift: added test #9596

Closed

stale bot added the State: stale State: The issue / PR has no activity for >185 days label Sep 21, 2019

aabadie removed the State: stale State: The issue / PR has no activity for >185 days label Oct 8, 2019

MichelRottleuthner closed this as completed Jan 24, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

xtimer: weird behavior of tests/xtimer_drift, bug? #5103

xtimer: weird behavior of tests/xtimer_drift, bug? #5103

haukepetersen commented Mar 18, 2016

haukepetersen commented Mar 18, 2016

jnohlgard commented Mar 18, 2016

haukepetersen commented Mar 18, 2016

haukepetersen commented Mar 18, 2016

jnohlgard commented Mar 18, 2016

kaspar030 commented Mar 20, 2016

haukepetersen commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

jnohlgard commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

PeterKietzmann commented Jan 26, 2017

haukepetersen commented Aug 28, 2017

smlng commented Aug 30, 2017

kYc0o commented Jul 17, 2018

Josar commented Jul 17, 2018 •

edited

Loading

Josar commented Jul 18, 2018

Josar commented Jul 18, 2018

kYc0o commented Jul 18, 2018

stale bot commented Sep 21, 2019

MichelRottleuthner commented Jan 24, 2020

xtimer: weird behavior of tests/xtimer_drift, bug? #5103

xtimer: weird behavior of tests/xtimer_drift, bug? #5103

Comments

haukepetersen commented Mar 18, 2016

haukepetersen commented Mar 18, 2016

jnohlgard commented Mar 18, 2016

haukepetersen commented Mar 18, 2016

haukepetersen commented Mar 18, 2016

jnohlgard commented Mar 18, 2016

kaspar030 commented Mar 20, 2016

haukepetersen commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

jnohlgard commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

kaspar030 commented Mar 21, 2016

haukepetersen commented Mar 21, 2016

PeterKietzmann commented Jan 26, 2017

haukepetersen commented Aug 28, 2017

smlng commented Aug 30, 2017

kYc0o commented Jul 17, 2018

Josar commented Jul 17, 2018 • edited Loading

Josar commented Jul 18, 2018

Josar commented Jul 18, 2018

kYc0o commented Jul 18, 2018

stale bot commented Sep 21, 2019

MichelRottleuthner commented Jan 24, 2020

Josar commented Jul 17, 2018 •

edited

Loading