joe_her wrote on Monday, October 02, 2017:
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
richarddamon wrote on Monday, October 02, 2017:
Do you have Tickless Idle enabled? That will (as its name sort of says) make tick interrupts not happen at times.
rtel wrote on Monday, October 02, 2017:
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).
joe_her wrote on Monday, October 02, 2017:
configUSE_TICKLESS_IDLE 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
joe_her wrote on Tuesday, October 03, 2017:
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).
joe_her wrote on Tuesday, October 03, 2017:
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
joe_her wrote on Tuesday, October 03, 2017:
I set TickPriority to 2, stil the same.
What am I missing?
rtel wrote on Tuesday, October 03, 2017:
HAL_NVIC_SetPriority(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:
joe_her wrote on Tuesday, October 03, 2017:
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
rtel wrote on Tuesday, October 03, 2017:
HAL_NVIC_SetPriority(OTG_FS_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY , 0);
Not sure about the parameters here - are the second and third parameters
the right way around?
joe_her wrote on Tuesday, October 03, 2017:
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 IRQn_Type 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_NVIC_SetPriority(IRQn_Type IRQn, uint32_t PreemptPriority, uint32_t 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
rtel wrote on Tuesday, October 03, 2017:
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.
joe_her wrote on Wednesday, October 04, 2017:
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 
joe_her wrote on Wednesday, October 04, 2017:
Solved.
As I suspected from the begininig it was a portENTER_CRITICAL. since it was in a piece of code which normally runs very rarly (write_SPI_EEPROM), 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 ENTER_CRITICAL when a mutex is much better.
rtel wrote on Wednesday, October 04, 2017:
Thanks for taking the time to report back.