xtimer race condition

ZetaR · 31 March 2018 06:36

Hello all,

I have had some odd problems with a PR I am attempting to finalize:

cpu/atmega_common: RTT and RTC support

github.com/RIOT-OS/RIOT

cpu/atmega_common: RTT and RTC support

RIOT-OS:master ← ZetaR60:RIOT_atmega_rtt_rtc

opened 05:01AM - 28 Mar 18 UTC

ZetaR60

+675 -0

This adds RTT and RTC support to the ATmegas. It is currently partially working …on ATMega1284P using the mega-xplained board. So far as I can tell, the timer used with the real-time crystal is the same across all supported ATmegas, so if another board is added with a RTC crystal it should work right away. The crystal cannot be added to any of the Arduino boards without soldering, unfortunately. There are a few problems with the code that I need to work out, but I need some advice on how to proceed: - The use of RTC_NUMOF in rtt.c does not work, but I am not sure what to use to guard the RTC code. - The use of thread_yield while waiting for busy conditions to clear lags messages in tests/periph_rtt a long time. But the wait can be up to 70ms, which seems really long to just spin if xtimer is not enabled. - periph_rtt is required for the RTC to work, but I don't know how to add this dependency without adding it for a bunch of stuff that doesn't need it (e.g. it must be added to FEATURES_REQUIRED in tests/periph_rtc). - ld does not seem to be able to find mktime and gmtime_r for rtc.c, leading to a 'undefined reference' error during linking. The RTT code is based on some prior work by Robert Hartung in #7604

When working with the real-time timers, there are a number of times that you have to wait a few of the slow clock cycles to go by. I am using xtimer_usleep to sleep the thread temporarily. But! xtimer causes the code I am using to hang. Debugging it is difficult, because anything sending debug messages over UART causes the problems to disappear!

I have been editing and running various numbers: xtimer_usleep(8); 8 and bigger fail xtimer_usleep(7); 7 and smaller work

Bigger numbers make them fail!

Here is a snippet of the offending code:

void __asynch_wait(uint8_t num_cycles) { /* Wait until all busy flags clear */ while( ASSR & ((1 << TCN2UB) | (1 << OCR2AUB) | (1 << OCR2BUB) > (1 << TCR2AUB) | (1 << TCR2BUB)) ) { #ifdef MODULE_XTIMER /* Sleep for num_cycles RTC cycles */ xtimer_usleep(num_cycles * 35 * US_PER_MS); #else /* Suppress unused parameter warning */ (void)num_cycles;

thread_yield(); #endif } }

Anyone have any ideas on what is going on?

Sincerely, Matthew

Joakim_Nohlgard · 31 March 2018 07:03

Hi Matthew, My guess is that you are running that function with interrupts disabled, which blocks the xtimer timeouts. The reason that short sleeps work in xtimer is that internally that is handled as a spin, while longer timeouts are handled by setting a hardware timer target. You can try using xtimer_spin instead of usleep, but chances are your PR will not be merged if you are using xtimer_spin with long timeouts. xtimer_spin is a busy wait which should be used only for very short periods, since it will be obstructing other parts of the system from running while you are spinning.

Best regards, Joakim