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, tm_callback); 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?

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, tm_callback); 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?

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

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

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?

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

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.