Writing Internal Flash disturbing RTOS scheduler in trustzone environment

I am working on an ARM-cortex M33 ,based controller (STM32U575) with trsutzone enabled environment.
My RTOS scheduler as recommended is in non-secure region , and Tasks are devided as secure and non-secure.
Now when i am trying to write controllers internal Flash in secure side , RTOS tasks are either getting stuck or starts executing unexpectedly .
Seems RTOS scheduler is somehow getting affected because of internal Flash write operation.

I have tried following but got no solution for this :

  1. Disabling All interrupts before writing to Flash and enabling all interrupts after it.
  2. Suspending all RTOS tasks before writing to Flash (vTaskSuspendAll) and resuming(xTaskResumeAll) all tasks after it.
  3. RTOS portENTER_CRITICAL() before writing to Flash and portEXIT_CRITICAL() after it.

none of above resolves the scheduler hanging issue.

I there any specific way to handle internal Flash in RTOS trustzone enabled environment ,that i am missing ??

I’m not sure about a relation to trustzone, but usually it’s not possible to execute code or access data in internal flash while erasing/writing to it. Means that the flash access code/data must be located in RAM and you have to ensure that neither task nor ISR code (if located in flash) is executed while erase/writing the flash.
So global interrupt disable/enable is a reasonable approach to ‘halt/resume’ the remaining application while updating the internal flash.
Well, and make sure that the flash update code is not overflowing the stack and works correctly. Then the application should seamlessly continue after the update procedure.

On further debugging it is identified that the issue is not beause of writing into internal flash.
So, i have commented out internal flash writing routine and kept a significant delay(~4sec ) between DISABLE_ALL_INTERRUPTS and ENABLE_ALL_INTERRUPTS.

Seems like RTOS schedular is misbehaving if All interrupts are disabled for a significant amount of time.
Any suggestions ?

Since the scheduler needs to use interrupt to determine that it is time to (or even be able to) switch to another task, the period during a DISABLE_ALL_INTERRUPTS will stop the scheduler.

Answer, don’t disable all interrupts (or even the interrupts like the tick time) or don’t expect scheduling to happen.