TickHook delayed?

I added GPIO toggle in vApplicationTickHook(), in order to get a 1Khz output (depending on a flag). It works, but out frequency changes from 500Hz (change every 1 ms) to every 7 ms, for 8 cycles, then its OK, and again, 8 cycles with 7ms … and so on. I am confused, what can influence the vApplicationTick frequency? I search for enter_CRITICAL but did not find a reason with that. Any idea? STM32F4. Thanks

TickHook delayed?

Do you have Tickless Idle enabled? That will (as its name sort of says) make tick interrupts not happen at times.

TickHook delayed?

Try using the trace tool to see what the application is doing when the ticks are suppressed. Are you running the tick at the lowest priority? If so, what other interrupts are running. If you are using the STM32 cube drivers then you may have to run the tick interrupt at the highest priority (which is not normally recommended, but some of the ST drivers rely on it).

TickHook delayed?

configUSETICKLESSIDLE is 0. I found a task , which when disabled, the frequncy is stable. this task is has nothing special. It blocks for 250ms using eventGroup: (the eventbit is set by another xTimer, as I need this to run every 250ms as accurate as possible)
tickBits = xEventGroupWaitBits(x250msEvBits,InletEvBit,pdTRUE,pdFALSE,2000);
it has a non blocking xQueueRec:
if(xQueueReceive(inletCmdQue,&iCmd,0) == pdPASS)
{
.
.
}
And a non-blocking xqueuSend:
xQueueSend(inletStatedQue,&iStat,0);

a get tick:
    xTime2 = xTaskGetTickCount();
and thease are all the FreeRTOS calls in that task. Which one can create the problem? Just thinking, can a stack oveflow do that, without crashing the program? (I will check first thing in the morning, by increasing task stack size) Thanks

TickHook delayed?

I found a bug in my program. It was a -1 read from uninitialized eeprom, that should never be negative (if I had a $ for every time I used int instead of uint). This bug created many fast calls to GPIO_writes, which were not needed, but so what? nothing really wrong with that. Fixing this solved the problem. Whoever, I still can’t figure out how this had any effect on the tick interrupt timing, It’s a mystery (for now).

TickHook delayed?

Well, I thought it is solved, but I was wrong. This is sysTick IRQ setting:
HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority ,0);
The current setting of TickPriority is 15, which makes it the LOWEST priority in my application, Should I set it to 1? Why it is not commanded, what problems can I expect? Thanks

TickHook delayed?

I set TickPriority to 2, stil the same. What am I missing?

TickHook delayed?

HALNVICSetPriority(SysTick_IRQn, TickPriority ,0);
You should not be using a pre-emption priority. Are you setting the priority grouping as described by the red text under “Preempt Priority and Subpriority? on this page: http://www.freertos.org/RTOS-Cortex-M3-M4.html

TickHook delayed?

Yes, this is the code. (part of usb host )
 /* Peripheral interrupt init*/
/* Sets the priority grouping field */
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
HAL_NVIC_SetPriority(OTG_FS_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY , 0); 
    HAL_NVIC_EnableIRQ(OTG_FS_IRQn);
Anything wrong here? I thought that only ENTER_CRITICAL could hold the sysTick interrupt. In my case it is very ordered way, it happens every 130 ms aprox, for exactly 8 cycles. Nothing random… I am chasing this for 2 days and one night, any help/idea will be appreciated very much. Thanks

TickHook delayed?

HALNVICSetPriority(OTGFSIRQn, configLIBRARYMAXSYSCALLINTERRUPTPRIORITY , 0);
Not sure about the parameters here – are the second and third parameters the right way around?

TickHook delayed?

I think you are onto someting here, (my confidence not too high right now ) /** * @brief Sets the priority of an interrupt. * @param IRQn: External interrupt number. * This parameter can be an enumerator of IRQnType enumeration * (For the complete STM32 Devices IRQ Channels list, please refer to stm32f4xx.h file) * @param PreemptPriority: The pre-emption priority for the IRQn channel. * This parameter can be a value between 0 and 15 * A lower priority value indicates a higher priority * @param SubPriority: the subpriority level for the IRQ channel. * This parameter can be a value between 0 and 15 * A lower priority value indicates a higher priority.
* @retval None */ void HAL
NVICSetPriority(IRQnType IRQn, uint32t PreemptPriority, uint32t SubPriority) … As you wrot “You should not be using a pre-emption priority” I did I swap parameters, didn’t i? and if I did, shoul I set the 2nd parameter to 0 or 15 ? Thanks very much

TickHook delayed?

I think the pre-emption priority should be zero, the only valid value if you have set the priority group as per previous posts in this thread.

TickHook delayed?

Not the solution. When I disable pre-emption as above, the problem persists. But when I insert a USB device, I get a failed assertion:
The following links provide detailed information:
        http://www.freertos.org/RTOS-Cortex-M3-M4.html
        http://www.freertos.org/FAQHelp.html */
        configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );
So I guss my initial settings are OK 🙁

TickHook delayed?

Solved. As I suspected from the begininig it was a portENTERCRITICAL. since it was in a piece of code which normally runs very rarly (writeSPIEEPROM), I did not suspect it. Woever, it did run in a loop which would wear the EEPROM, and that bug also was found. The lesson is that one should not use ENTERCRITICAL when a mutex is much better.

TickHook delayed?

Thanks for taking the time to report back.