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 <[email protected]>: > 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=<optimized out>) > 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=<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@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, > > -- > > *Aurélien FILLAU* > > Co-founder at we-sens.com > > > 2018-01-16 19:03 GMT+01:00 Aurélien Fillau <[email protected]>: > >> 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 <[email protected]>: >> >>> 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 <[email protected]> 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 < >>> [email protected]> 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" <[email protected]> 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 >>> > [email protected] >>> > https://lists.riot-os.org/mailman/listinfo/users >>> > >>> > _______________________________________________ >>> > users mailing list >>> > [email protected] >>> > 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
_______________________________________________ users mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/users
