Systick interruption doesn't trigger when handling another interrupt
You can, if your processor allows it (it should, since I believe all of that series are Cortex M4 based), set the Systick Interrupt to a higher priority than the other interrupts and then find out if you can make your compiler/processor not turn off interrupts globally while processing an interrupt.
That is, if you want to have delays in your interrupts.
Hint: You shouldn't want that.
Interrupts are meant to run efficiently and quickly to handle important events that are critical. If something needs a delay beyond a couple of ASM(&quot;__volatile__ NOP\n NOP\n NOP\n&quot;)'s, it's probably not something you want in your interrupt.
If you have a &quot;heavy task&quot; that gets triggered by an interrupt it's much neater to write:
uint32_t taskFlags;  // semafore register, can also be any other data type that fits your flags (1ul --&gt; uint32_t or larger!)
#define HANDLE_MY_INTERRUPT_STUFF    (1ul&lt;&lt;0) // Define a flag for interrupt things.

void main(void) {
    while(1) {
        if(taskFlags &amp; HANDLE_MY_INTERRUPT_STUFF) { // Check the flag
            // Do your interrupt stuff
            // Allowed to have many delays and other weird stuff
            
            taskFlags &amp;= ~HANDLE_MY_INTERRUPT_STUFF; // Clear the flag.
        }
    }
}

InterruptHandler(void) {
    taskFlags |= HANDLE_MY_INTERRUPT_STUFF;  // set the flag
}

And now suddenly all that heavy processing gets done in the main loop, where it can be interrupted and all and won't harm any other time-critical things. But only triggered by the interrupt source, through the flags.
Although through the flags you will of course risk a slight variable delay in execution, it's always a balancing act.
Late addition:
Between processor types the delay will usually be between 4 and 40 clock cycles + average other interrupt code execution, so at a couple MHz using a 10ms delay will usually already marginalise that delay and its variation.)