cancel
Showing results for 
Search instead for 
Did you mean: 

Do Interrupt Priorities Have To Start At Zero?

Christensen.Tyler
Associate II

I've been fighting a very subtle strange QSPI bug for a while now where data is occasionally spuriously clocked out unexpectedly. Without going into too much detail about that right now, my question is about interrupt priorities. I found what appears to be a fix that makes my spurious transmissions go away. Previously my interrupts were set to priorities 1 through 7 with no interrupt assigned priority level 0. I decreased each priority by 1 so that now they are priorities 0 through 6 (same relative priorities, just subtracted one from each one, no re-ordering). With only that change, my problem with the QSPI peripheral spurious transmissions goes away. I went back and forth a few times because I just couldn't believe the result, but it really does make the bug disappear with only that single change.

Is there any logic behind this? I've never worried about having priorities 0-N before and lots of my programs have fairly random priority numbering schemes that don't necessarily start at 0. I can't find any documentation that this should matter or any discussions on the topic.

12 REPLIES 12
Pavel A.
Evangelist III

If he indeed uses HAL for USB, it can be collision with SysTick interrupt which by default has priority 0.

HAL_Delay gets disturbed and so on.

-- pa

> If he indeed uses HAL for USB, it can be collision with SysTick interrupt which by default has priority 0.

> HAL_Delay gets disturbed and so on.

Great catch, Pavel!

Indeed, the SysTick is not enabled/disabled in NVIC (but in its own control register), and its priority is not set in NVIC either (but in SCB_SHPRx). Very confusing, probably has historical roots, and I was caught by this at least once, too.

Still the shuffling of interrupts IMO hides the problem only coincidentally.

JW

[doubled post courtesy of forum software bug]