Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

xTimerChangePeriodFromISR overhead? BUG?

Posted by seagull_kamome on June 20, 2018

Hi FreeRTOS developer team. I'm still testing the kernel.

~~~ static TimerHandlet tm; static TickTypet volatile isrtick, tmtick; static uint32_t volatile flags = 1;

static void mysystickhandler(void) { xPortSysTickHandler(); if (flags == 0) { isrtick = xTaskGetTickCountFromISR(); BaseTypet woken = pdFALSE; xTimerChangePeriodFromISR(tm, 100, &woken); //xTimerStartFromISR(tm, &woken); flags = 1; portYIELDFROMISR(woken); } }

static void tmcallback(TimerHandlet tmr) { tm_tick = xTaskGetTickCount(); }

static void testtaskmain(void* args _unused) { isrtick = tmtick = 0; tm = xTimerCreate("TM", 100, pdFALSE, (void*)1, tmcallback); TickType_t t1 = xTaskGetTickCount(); flags = 0; vTaskDelay(1000);

// I expected "t1=0 isr_tick=1 tm_tick=100".
// xTimerStartFromISR seems oKay, but I got "t1=0 isr_tick=0 tm_tick=193" for xTimerChangePeriodFromISR.
// what's an extra 93 ticks? why is isr_tick not one but zero?
configPRINTF("t1=%d isr_tick=%d tm_tick=%d ", t1, isr_tick, tm_tick);
vTaskDelete(NULL);

} ~~~

Why does xTimerChangePeriodFromISR makes extra 93ms? Is it a unavoidable overhead? or BUG?


xTimerChangePeriodFromISR overhead? BUG?

Posted by rtel on June 20, 2018

static void mysystickhandler(void) { xPortSysTickHandler(); if (flags == 0) { isrtick = xTaskGetTickCountFromISR(); BaseTypet woken = pdFALSE; xTimerChangePeriodFromISR(tm, 100, &woken); //xTimerStartFromISR(tm, &woken); flags = 1; portYIELDFROMISR(woken); } }

This is not a recommended way of adding code to the systick handler - please use the tick hook function instead. https://www.freertos.org/a00016.html

static void tmcallback(TimerHandlet tmr) { tm_tick = xTaskGetTickCount(); }

static void testtaskmain(void* args _unused) { isrtick = tmtick = 0; tm = xTimerCreate("TM", 100, pdFALSE, (void*)1, tmcallback); TickType_t t1 = xTaskGetTickCount(); flags = 0; vTaskDelay(1000);

 // I expected "t1=0 isr_tick=1 tm_tick=100".
 // xTimerStartFromISR seems oKay, but I got "t1=0 isr_tick=0 tm_tick=193" for xTimerChangePeriodFromISR.
 // what's an extra 93 ticks? why is isr_tick not one but zero?
 configPRINTF("t1=%d isr_tick=%d tm_tick=%d ", t1, isr_tick, tm_tick);
 vTaskDelete(NULL);

}

Why does xTimerChangePeriodFromISR makes extra 93ms? Is it a unavoidable overhead? or BUG?

I will have to set this up to try and replicate it - but either 93ms is an age, not just a little bit of overhead, so something else is going on here.

Why did you replace the tick handler? What other tasks are running? What is the priority of the Timer task?


xTimerChangePeriodFromISR overhead? BUG?

Posted by rtel on June 20, 2018

Also - what is the tick frequency and have you validated it is what you think it is?


xTimerChangePeriodFromISR overhead? BUG?

Posted by seagull_kamome on June 21, 2018

This is not a recommended way of adding code to the systick handler - please use the tick hook function instead.

I knew it, but thank you. That code I posted is used for only testing.

Why did you replace the tick handler?

Just for test. I'm writing an evaluation report of FreeRTOS for our project that considering to move into it. XXXFromISR APIs need any ISR. A systick handler looks handy for a portable automated test, I thought.

What other tasks are running? What is the priority of the Timer task?

Logging task at priority 15, Timer task at 15 and that testtask has priority 2. also Idle at 0. configMAXPRIORITY is 16.

That Logging task was created based awsloggingtaskdynamimcbuffers.c, but using a static ring buffer and direct task notifiy instead of malloc/queue.

I had tried to move Logging task's priority into 14. But no result changed.

Also - what is the tick frequency and have you validated it is what you think it is?

Tick frequency is 1k Hz. I have no validated it with scope yet. However, I think it is no big matter, because xTimerStartFromISR gives me a correct result "t1=0 isrtick=0 tmtick=100".


xTimerChangePeriodFromISR overhead? BUG?

Posted by rtel on June 21, 2018

With the priorities as you have then the logging task could prevent the task you are taking the times from from executing. Try setting the logging task to priority 0 so it is lower than the test task. Also, the time discrepancy is so large I wonder if your logging might be blocking the system by either disabling interrupts or using semi-hosting?

Sorry if you said already - but which dev board are you using?


xTimerChangePeriodFromISR overhead? BUG?

Posted by rtel on June 21, 2018

I've just tried running your exact code and, as expected, got the result you expected to get. Screenshot attached.

Attachments

test_screen_shot.jpg (87920 bytes)

xTimerChangePeriodFromISR overhead? BUG?

Posted by seagull_kamome on June 21, 2018

I took a task trace. and, now I understand that using a systick handler is really bad idea when TICKLESSIDLE enabled. I'm very sory. This is totally my mistake. I have tried to disable configTICKLESSIDLE, and got a result I expedted.

Thank you.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo, Nuvoton Cortex-M23 demo & STM32H745 dual core (AMP) demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Mediatek

Renesas

RISC-V

SiFIve RISC-V

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner