Do Interrupt Priorities Have To Start At Zero?

[Christensen.Tyler]

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.

[Pavel A.]

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

[waclawek.jan]

> 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

[waclawek.jan]

[doubled post courtesy of forum software bug]