[riot-users] Issue with xtimer_usleep

Aurélien Fillau aurelien.fillau at gmail.com
Wed Jan 17 15:06:33 CET 2018


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 at entry=0) at
/home/aurelien/we-sens/RIOT-dev/RIOT/cpu/stm32_common/periph/timer.c:95
#1  timer_read (tim=tim at 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=<optimized out>)
    at /home/aurelien/we-sens/RIOT-dev/RIOT/sys/xtimer/*xtimer_core.c:65*
#4  _xtimer_set_absolute (timer=timer at entry=0x20000ebc <main_stack+1416>,
target=<optimized out>)
    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 at entry=0x20000ebc
<main_stack+1416>, offset=offset at entry=101,
    long_offset=long_offset at entry=0) at
/home/aurelien/we-sens/RIOT-dev/RIOT/sys/xtimer/*xtimer_core.c:107*
#7  0x0800c4ae in _xtimer_tsleep (offset=offset at entry=101,
long_offset=long_offset at 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,

-- 

*Aurélien FILLAU*

Co-founder at we-sens.com


2018-01-16 19:03 GMT+01:00 Aurélien Fillau <aurelien.fillau at gmail.com>:

> 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 :)
>
> Regards,
>
> Aurélien
>
> 2018-01-16 11:27 GMT+01:00 smlng <s at mlng.net>:
>
>> 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
>>
>> > On 16. Jan 2018, at 11:17, Jose Alamos <jialamos at uc.cl> wrote:
>> >
>> > 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é
>> >
>> > Le lun. 15 janv. 2018 à 21:59, Aurélien Fillau <
>> aurelien.fillau at gmail.com> a écrit :
>> > 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
>> >
>> > Le 15 janv. 2018 10:56, "Jose Alamos" <jialamos at uc.cl> a écrit :
>> > 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é
>> >
>> > _______________________________________________
>> > users mailing list
>> > users at riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/users
>> >
>> > _______________________________________________
>> > users mailing list
>> > users at riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/users
>>
>>
>
>
> --
>
> *Aurélien FILLAU*
>
> Co-founder at we-sens.com
>



-- 

*Aurélien FILLAU*

Co-founder at we-sens.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/users/attachments/20180117/034208a0/attachment.html>


More information about the users mailing list