systick interrupt priority

[jono-tree]

Posted on April 26, 2014 at 23:58

Hi all,

When my program is in an interrupt caused by an external rising edge, the systick interrupt no longer occurs. My first thought was that the priority of the systick was lower than that of my function, so I used NVIC_SetPriority and NVIC_GetPriority to obtain the priorities of both of them, and change them to ok levels. This led me to other more fundamental questions which I would appreciate help to awsner. Finding out the systick prioirty was easy enough, because the

IRQn_Type IRQn

parameter was easy to locate from the code, since it already appears in SysTick_Config function. For my exti line however, I can't find which parameter gets passed to it!! Thats because I configured it in STM CMSIS, ie with the lines NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x01; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x01; When I tried to look inside the CMSIS levels of abstraction, the closest thing I could find to the set prioirty function was the thing (macro?! constant?! This is something about which I'd like clarification, it was like a functionk but with square brackets, and then just equalled something...) NVIC->IP, something which I don't understand. Its used like: NVIC->IP[NVIC_InitStruct->NVIC_IRQChannel] = tmppriority; So if anyone can clarify what that thing is, where the _IRQn definitions come from - I can't find them in my project using cntrl+shif+f, or why my systick handler is not being called in general, I'd greatly appreciate it. So far I've tried setting the systick handler to have a lower (higher) priority than the exti interrupt with no luck using the functions NVIC_SetPriority and NVIC_GetPriority Best wishes, Jonathan #stm32f4 #systick #priority

[Tesla DeLorean]

Posted on April 27, 2014 at 01:37

I might ponder why it's dwelling the the EXTI IRQHandler so much.

STM32F4xx_DSP_StdPeriph_Lib_V1.3.0\Libraries\CMSIS\Device\ST\STM32F4xx\Include\stm32f4xx.h

RCC_ClocksTypeDef RCC_Clocks;
NVIC_InitTypeDef NVIC_InitStructure;
/* Configure the preemption priority and subpriority:
- 1 bits for pre-emption priority: possible value are 0 or 1
- 3 bits for subpriority: possible value are 0..7
- Lower values gives higher priority
*/
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_1);
NVIC_InitStructure.NVIC_IRQChannel = BUTTON_EXTI_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
/* SysTick end of count event each 1ms */
RCC_GetClocksFreq(&RCC_Clocks);
SysTick_Config(RCC_Clocks.HCLK_Frequency / 1000);
/* Configure the SysTick handler priority */
NVIC_SetPriority(SysTick_IRQn, 0x0);

[jono-tree]

Posted on May 03, 2014 at 17:26

Never quite got to the bottom of this one, although would like to revisit it one day when there's time. I asked this question on behalf of a project partner, but we decided to just sack it off and implement delays with for loops in the end.

[Tesla DeLorean]

Posted on May 04, 2014 at 01:44

For marking time in loops using a free running TIMx->CNT or DWT_CYCCNT avoids any dependency on interrupts, etc.

[roberts]

Posted on September 24, 2014 at 14:04

I just discovered what may be a related issue.

HAL_SYSTICK_Config() sets the systick priority to a value from stm32l051xx.h, overriding the higher priority which I'd set in STM32CubeMX. I set interrupt priority to 1, and HAL_SYSTICK_Config() set it back to 3. Result: SPI interrupt locked up waiting for a timeout which never came, because SPI interrupt was now higher priority than the tick! Rob