Issue with xtimer_usleep

Hi Aurélien:

Could you give us more information about your platform? (e.g CPU model, etc).

Are you getting the same results with different values of XTIMER_BACKOFF?

Cheers

José

Hi,

Thank you for your replies and i apologize for the delay in responding. We are working on custom boards now that embeds a STM32L073CZT6 CPU. We have started the project with a nucleo-l073rz board (STM32L073RZT6), and i think it can be easily reproduced on this board. xtimer_usleep() is called from thread context (not from an isr context). I didn’t try to change XTIMER_BACKOFF because i have stabilized it to faced another issue (Indeed, xtimer_usleep() was sleeping my task forever if XTIMER_BACKOFF was too small). This “blocking while” can occur at startup or after 24 hours or even after a longer period of time, or even never on some boards, that’s why it is not easily reproducible.

Regards,

Aurélien

Hi Aurelién,

I’m currently running some experiments in a nucleo-L073RZ, calling xtimer_usleep with small random values, just to check if I can reproduce the issue.

On the other side, is the same issue happening if you increase the XTIMER_BACKOFF?

Cheers,

José

Hi all,

there is also a tests application for (very) short xtimer_sleeps, i.e., `tests/xtimer_usleep_short`. It was "specifically designed" to find issues with XTIMER_BACKOFF and such.

Cheers,   Sebastian

Hi,

@José :

Thank you for the time you take about this issue. Here is the kind of test i’m running to trigger it :

for (uint16_t i=0; i<1000; i++) { xtimer_usleep(10); }

for (uint16_t i=0; i<1000; i++) { xtimer_usleep(100); }

I have also decreased AHB speed bus to save power, maybe it comes from that !

periph_conf.h :

#define CLOCK_HSI (16000000U) /* internal oscillator / #define CLOCK_CORECLOCK (16000000U) / desired core clock frequency */

/* configuration of PLL prescaler and multiply values / / CORECLOCK := HSI / CLOCK_PLL_DIV * CLOCK_PLL_MUL / #define CLOCK_PLL_DIV RCC_CFGR_PLLDIV4 #define CLOCK_PLL_MUL RCC_CFGR_PLLMUL4 / configuration of peripheral bus clock prescalers / #define CLOCK_AHB_DIV RCC_CFGR_HPRE_DIV8 / AHB clock -> 2MHz / #define CLOCK_APB2_DIV RCC_CFGR_PPRE2_DIV1 / APB2 clock -> 2MHz / #define CLOCK_APB1_DIV RCC_CFGR_PPRE1_DIV1 / APB1 clock -> 2MHz / / configuration of flash access cycles */ #define CLOCK_FLASH_LATENCY FLASH_ACR_LATENCY

/* bus clocks for simplified peripheral initialization, UPDATE MANUALLY! */ #define CLOCK_AHB (CLOCK_CORECLOCK / 8) #define CLOCK_APB2 (CLOCK_CORECLOCK / 8) #define CLOCK_APB1 (CLOCK_CORECLOCK / 8)

I will try to increase XTIMER_BACKOFF to see if the same issue occurs.

@Sebastian

I will try to launch “tests/xtimer_usleep_shor” on my platform.

Thx again for your help and the time you are spending on it :slight_smile:

Regards,

Aurélien

Hi,

I have tried to launch xtimer_usleep testing code but i didn’t succeed in compiling it, so i have copied it in my own code. The issue is still difficult to trigger.

Here is my backtrace when the issue occurs :

#0 0x0800959c in dev (tim=tim@entry=0) at /home/aurelien/we-sens/RIOT-dev/RIOT/cpu/stm32_common/periph/timer.c:95 #1 timer_read (tim=tim@entry=0) at /home/aurelien/we-sens/RIOT-dev/RIOT/cpu/stm32_common/periph/timer.c:96 #2 0x0800869a in _xtimer_lltimer_now () at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/include/xtimer/implementation.h:46 #3 0x08008934 in xtimer_spin_until (target=) at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/xtimer/xtimer_core.c:65 #4 _xtimer_set_absolute (timer=timer@entry=0x20000ebc <main_stack+1416>, target=) at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/xtimer/xtimer_core.c:181 #5 0x08008a4c in _xtimer_set (timer=0x20000ebc <main_stack+1416>, offset=101) at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/xtimer/xtimer_core.c:146 #6 0x08008a5e in _xtimer_set64 (timer=timer@entry=0x20000ebc <main_stack+1416>, offset=offset@entry=101, long_offset=long_offset@entry=0) at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/xtimer/xtimer_core.c:107 #7 0x0800c4ae in _xtimer_tsleep (offset=offset@entry=101, long_offset=long_offset@entry=0) at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/xtimer/xtimer.c:68 #8 0x080097c0 in _xtimer_tsleep32 (ticks=101) at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/include/xtimer/implementation.h:148 #9 xtimer_usleep (microseconds=101) at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/include/xtimer/implementation.h:162 #10 main () at /home/aurelien/we-sens/wesens-os/wesens-os/main_app/main.c:179

As you can see, this is when i want to use xtimer_usleep(101) ! On line 145 of xtimer_core.c, the target variable (=_xtimer_now() + offset) overflows a 16bits values and gives the following result : 0x3DFFA8. Then, when i call the line 181 : target + XTIMER_BACKOFF = 0x3E000C. And finally, the mask on line 63 deletes the most significant bits and at this moment target = 0xC. And after that, the probility after each evalutation of timer counter to be between 0 and 0x0C is very small, that’s why i’m blocked on line 65 (i suppose this is the same issue with values close to 0xFFFF and second “while” : line 66)

I have tried to change XTIMER_BACKOFF but it is just postponing the issue or hiding it for a certain period of time.

I’m still suspecting that’s my AHB bus speed (2MHz) that is highlighting this issue.

I add my timer configuration :

/**

  • @name xtimer configuration
  • @{ */ #define XTIMER_DEV TIMER_DEV(0) #define XTIMER_CHAN (0) #define XTIMER_WIDTH (16)

#define XTIMER_BACKOFF (100) #define XTIMER_ISR_BACKOFF (100) #define XTIMER_OVERHEAD (100) /** @} */

Best regards,

Hi,

Can i raise an issue on github for this bug or do i need to go further in my investigation ?

Regards,

Aurélien