SysTick_Handler suspended during other interrupts

[jmilliken]

Posted on August 13, 2013 at 17:12

Hello Allm

I am prototyping with the STM32 F3 Discovery board and using the ST standard peripheral library.  I am also using some example code that contains a function - Delay() - which uses the SysTick_Handler to decrement a global variable until it hits zero and then program functionality continues.  This all works fine as part of the main body of code. The problem occurs when I try to call this function from within some other interrupt that I have defined myself.  Specifically, I was trying to use Delay() to toggle a pin when I enter the DMA Transfer Complete interrupt. When I am in this interrupt, breakpoints in the SysTick_Handler show that it is never called again and the program crashes. Why does this happen?  Shouldn't SysTick automatically, through the core architecture, have a higher priority than any interrupt I define?  Does the SysTick clock get suspended for some reason during interrupt calls? The use of Delay is not strictly necessary - I am just using it so I can trigger a scope with a pin toggle - and if I take out that function call everything is fine.  But I would like to understand what is happening in case it has a farther-reaching consequences.  Thanks. -Jamie #stm32-systick

[jmilliken]

Posted on August 13, 2013 at 18:01

After some searching, I have found that the SysTick actually gets set to priority 15, so will lock up any interrupt with higher (lower number) preemption priority.  I was able to fix it with a simple call to NVIC_SetPriority(), but I still find this confusing.  In the Tech. Ref. Man., Table 30 shows it as having a higher natural priority than any user defined routines.  Why does this change in practice?

Also, I find it confusing to say ''low'' or ''high'' priority since ''low priority'' in the colloquial sense meaning ''not very important'' can easily be confused with literal ''low priority'' meaning low number and thus very important.  But that's just my own personal gripe, I guess.

[Tesla DeLorean]

Posted on August 13, 2013 at 18:16

Well there are several things at play.

The core does give it higher priority, but SysTick_Config() sets it to the least (15), ie will be stalled by anything else. So nominally you might expect it not to preempt others, and always be serviced last when others assert prior to tail-chaining. It's not an ''interrupt'' in the external sense, but a system handler. This impacts the NVIC functions that can be used with it's negative enumeration. There are 4-bits in the NVIC that control the sub-priority/preemption, but you also have to configure how those bits are apportioned. See NVIC_PriorityGroupConfig()