[riot-users] Issue with xtimer_usleep

Aurélien Fillau aurelien.fillau at gmail.com
Fri Jan 19 14:10:36 CET 2018


Hi,

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

Regards,

Aurélien

2018-01-17 15:06 GMT+01:00 Aurélien Fillau <aurelien.fillau at gmail.com>:

> 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
>



-- 

*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/20180119/8bf95ed2/attachment.html>


More information about the users mailing list