Alarm overflow - gettimeasticks

[tyler-potyondy]

While working on the OpenThread libtock-c port, @atar13 and @Samir-Rashid observed a bug on the nrf52840dk board attempting to use the gettimeasticks functionality. When tested with the following code:

    // code below abbreviated for demonstration
    for (int i = 0; i < NUM_SAMPLES; i++) {
        uint32_t cur_time_ms = gettimeasticks(&tv, NULL);
        clock_return[i] = cur_time_ms;
        delay_ms(1);
    }

    // print results
    for (int i = 0; i < NUM_SAMPLES; i++) {
        uint32_t item = clock_return[i];
        printf("item %d:\t %lu\n", i, item);  // output wraps around at about 128
    }

they observed that the the time in milliseconds wrapped around to zero approximately every 128 ms (see below)

item 26:         103
item 27:         107
item 28:         111
item 29:         115
item 30:         119
item 31:         123
item 32:         127
item 33:         0
item 34:         3
item 35:         7

Upon looking into this, it appears this is caused by a buffer overflow when performing the microsecond calculation in libtock/alarm_timer.c:

tv->tv_usec = (remainder * 1000 * 1000) / frequency;

The nrf52840DK board is configured to frequency = 32768Hz. The greatest possible remainder value is $remainder = frequency - 1$. Depending on __USE_TIME_BITS64, tv_usec is either uint32_t or uint64_t. In the case of tv_usec being of type unint32_t, the intermediate calculation $(remainder * 1000 * 1000)$ will overflow and result in the timer microsecond value appearing to rollover and reset.

A proposed fix to this (at the loss of ~1us of precision for the frequency = 32768Hz case) is to adjust the microsecond calculation. I detailed this precision concern and overflow concerns for varied frequencies in a comment within the function. This loss of precision only occurs for the frequency value of 32768Hz. All other frequencies defined in the kernel at kernel/src/hil/time.rs (e.g. 1KHz, 16MHz, etc) will not experience this loss of precision as the 3 least significant digits do not encode data.

@alistair23 your input would be appreciated on this since I believe you were using the gettimeasticks function. Please let me know if I overlooked some detail related to other board platforms timer frequency configuration.

Testing this on the nrf52840dk, this implementation now returns the expected behavior and no longer exhibits the "rollover" at 128 ms.

[alistair23]

This looks reasonable to me. The CI is failing though

[tyler-potyondy]

Formatting CI is passing now, but the build CI is still failing. Looking into the logs it appears to be an issue with ./cxx_hello. Testing locally, cxx_hello is building without issue. Any ideas as to what might be causing this?

[lschuermann]

Seems that we have a combination of a missing dependency specification (newlib for CXX targets), as well as a race condition in the CI:

libtock-libc++-10.5.0.zip: OK
Unpacking libtock-libc++-10.5.0.zip...
libtock-newlib-4.2.0.20211231.zip: OK
Unpacking libtock-newlib-4.2.0.20211231.zip...
Done upacking libtock-libc++-10.5.0.zip...
 CXX        main.cc
 CXX        main.cc
 CXX        main.cc
 CXX        main.cc
 CXX        main.cc
 CXX        main.cc
main.cc:1:10: fatal error: stdio.h: No such file or directory
    1 | #include <stdio.h>
      |          ^~~~~~~~~
compilation terminated.
make: *** [../../AppMakefile.mk:311: build/rv32imac/main.o] Error 1
make: *** Waiting for unfinished jobs....
main.cc:1:10: fatal error: stdio.h: No such file or directory
    1 | #include <stdio.h>
      |          ^~~~~~~~~
compilation terminated.
make: *** [../../AppMakefile.mk:311: build/rv32imc/main.o] Error 1
Done upacking libtock-newlib-4.2.0.20211231.zip...
 ⤤ Failure building ./cxx_hello
Rebuilding Verbose: ./cxx_hello

When I try to reproduce this locally make (presumably) orders the build steps differently and proceeds to build a C file first, which will cause newlib to be fetched. Then the C++ source is built, which fetches libc++. If the C++ object is built first and it depends on newlib, the build fails.

I'll attempt to fix and open a PR.

[lschuermann]

@tyler-potyondy Try rebasing on #367 and see if that helps.

[tyler-potyondy]

I rebased on #367 and that seems to have fixed the CI issue. @lschuermann thanks for resolving the issue!

[lschuermann]

Marking as blocked on #367 then. Nice to see that that fixed it!

[bradjc]

Need rebase

[tyler-potyondy]

Should be rebased and good to merge now.