2018-10-26 10:01 AM
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.
2018-10-27 05:21 PM
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
2018-10-28 03:58 AM
> 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
2018-10-28 03:58 AM
[doubled post courtesy of forum software bug]