Hi,

Looking at the ARM architecture code it seems that the SysTick interrupt
priority is currently the same as the highest priority an
application/driver can get. I.e. the same as interrupt priority 0
defined by IRQ_CONNECT macro.

Is this design intentional?

I've always assumed that SysTick has higher IRQ priority than the
application and it is the primary reason why we reserve 2 IRQ priority
levels for the kernel.

The long version:

In my application I need to measure timing. I do it using
k_cycle_get_32() function. Some of the measurements have to be done
within an interrupt handler. In my case the interrupt handler is
responsible for setting up continuous DMA transfer of audio data and
runs at priority 0. I have noticed that some of the timing measurements
are - temporarily - off by the duration of one system tick. The reason
turned out to be SysTick interrupt priority. To solve the problem it's
enough to set the priority of the application/driver interrupt handler
to minimum 1. It feels however strange that we need to do it. Also, this
SysTick behavior is currently not documented.

Regards,
Piotr