Hi Oliver. Your temporary solution should work OK. Theoretically it could be made into a FreeRTOS configuration option, even though it is not currently an option. (I think that’s what Gaurav meant.)
But a better fix would be to lower the priority of the secure exceptions that make FreeRTOS API calls. They must be lower priority (higher value) than the deprioritized max syscall priority. Here’s the Architectural Reference Manual’s visual indication of what happens to non-secure interrupts in a TZ application that uses FreeRTOS:
On STM32U5, there are 4 priority bits. Let’s say you set configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY to 5. So priorities 5 through 15 are good for FreeRTOS API calls. However, on the secure side, only 10 through 15 are good for FreeRTOS API calls. That’s because the deprioritized configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY is 10, not 5. Can you give that a try?
As a side note, unfortunately FreeRTOS cannot validate interrupt priorities of secure interrupts because the ARMv8-M architecture prevents the nonsecure FreeRTOS API function from determining which secure interrupt is active. So you’re on your own setting the correct interrupt priorities for secure interrupts that call FreeRTOS API functions.