# Writing Internal Flash disturbing RTOS scheduler in trustzone environment **URL:** \ **Category:** Kernel\ **Created:** [December 30, 2022, 8:26am UTC](https://forums.freertos.org/t/writing-internal-flash-disturbing-rtos-scheduler-in-trustzone-environment/16475 "2022-12-30T08:26:47Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![vishvender](https://avatars.discourse-cdn.com/v4/letter/v/f0a364/32.png) [@vishvender](https://forums.freertos.org/u/vishvender)\ **Post date:** [December 30, 2022, 8:26am UTC](https://forums.freertos.org/t/writing-internal-flash-disturbing-rtos-scheduler-in-trustzone-environment/16475/1 "2022-12-30T08:26:47Z")
Hi, 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 ?? ---
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [December 30, 2022, 8:43am UTC](https://forums.freertos.org/t/writing-internal-flash-disturbing-rtos-scheduler-in-trustzone-environment/16475/2 "2022-12-30T08:43:21Z")
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. ---
**Author:** ![vishvender](https://avatars.discourse-cdn.com/v4/letter/v/f0a364/32.png) [@vishvender](https://forums.freertos.org/u/vishvender)\ **Post date:** [January 4, 2023, 4:09am UTC](https://forums.freertos.org/t/writing-internal-flash-disturbing-rtos-scheduler-in-trustzone-environment/16475/3 "2023-01-04T04:09:57Z")
Hi, 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 ? ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [January 4, 2023, 4:30am UTC](https://forums.freertos.org/t/writing-internal-flash-disturbing-rtos-scheduler-in-trustzone-environment/16475/4 "2023-01-04T04:30:24Z")
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.