Quality RTOS & Embedded Software

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




Loading

TickHook delayed?

Posted by joe_her on October 2, 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


TickHook delayed?

Posted by richarddamon on October 2, 2017

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


TickHook delayed?

Posted by rtel on October 2, 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).


TickHook delayed?

Posted by joe_her on October 2, 2017

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?

Posted by joe_her on October 3, 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).


TickHook delayed?

Posted by joe_her on October 3, 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


TickHook delayed?

Posted by joe_her on October 3, 2017

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


TickHook delayed?

Posted by rtel on October 3, 2017

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?

Posted by joe_her on October 3, 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


TickHook delayed?

Posted by rtel on October 3, 2017

HALNVICSetPriority(OTGFSIRQn, configLIBRARYMAXSYSCALLINTERRUPTPRIORITY , 0);

Not sure about the parameters here - are the second and third parameters the right way around?


TickHook delayed?

Posted by joe_her on October 3, 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 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 HALNVICSetPriority(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?

Posted by rtel on October 3, 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.


TickHook delayed?

Posted by joe_her on October 4, 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 :-(


TickHook delayed?

Posted by joe_her on October 4, 2017

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?

Posted by rtel on October 4, 2017

Thanks for taking the time to report back.


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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