Disabling IRQ during FlexSPI operations (erase, write, etc.) stops SysTick

[SpoonMan]

Hi everybody,

referring to: 

https://github.com/NXP/vizn3d_smartlock_oobe/tree/rt117x/smart_lockhttps://github.com/NXP/vizn3d_sma...

I correctly see that, because of XIP, sln_flash.c and related have been relocated to SRAM_ITC_cm7 through linkscripts and that during erase, write, etc. operations interrupts and D-Cache are disabled:

But then I noticed that, because this project is based on RTOS, SysTick ISR is suspended during relatively long calls (sector erase may be 300 ms long according to the datasheet):

I know we're talking about 300 ms, which are not a lifetime but anyway are equivalent to 300 ticks skipped at every erase operation (and because of the filesystem we may have a lot of consecutive erase operation).

So the questions are:

- how this would affect RTOS scheduling?

- disabling ALL interrupts during such long operation is good practice?

[kerryzhou]

Hi @SpoonMan ,

  Please take it easy, I am glad to discuss it with you, so please feel free if you have any questions, you are always welcome!

   Seems some misunderstanding!

   ROM API doesn't need to be put into the RAM, just in Flash is OK.

   fsl_flexSPI needs to be put into the internal RAM

  So, ROM API in flash= fsl_flexSPI in RAM

   Then, ISR handler, vector table put to the internal RAM, it is used to resolve the issue when the flash is busy, interrupt code in the flash will meet hardfault issues.

So, I think, if you have time, you can test to put the ISR handler to the internal RAM, then when your flash is operated, the timer interrupt should still work.

If you still meet issues, I may also find time to help you do an example, but that need time, it's better to create a new case about it.

Best Regards,

Kerry

[SpoonMan]

Glad to discuss with you too!

Ok, now the difference is clear to me.

But I still cannot figure out what's the advantage of using ROM API over FlexSPI API, because the point is if I want to do something "in parallel" (e.g. I want to execute another RTOS task or ISR code while QSPI Flash is performing some program/erase operation) I'm forced to move such code to RAM in both cases... so, what's the advantage of having ROM API in Flash? Its just a matter of having to move FlexSPI API to RAM?

[kerryzhou]

Hi @SpoonMan ,

  Yes, just having to move FlexSPI API to RAM, but ROM API doesn't need it!

  So, if you also can accept moving the flexSPI API to RAM, you also don't need to use the ROM API. 

Best Regards,

Kerry

[SpoonMan]

Hi @kerryzhou 

I think in my case it's not worth to convert my actual driver which is coded on top of FlexSPI API to ROM API just for this (small, in my opinion) advantage... basically I was searching for a method to have a smoother execution of all tasks during QSPI Flash operations (SysTick stopping was just the top of the iceberg)...

In any case, thanks for the clarification!

[kerryzhou]

Please give me more time to check your issues, really so long.

These days, really a lot of cases in the queue, we are a little overflow, please keep patient, thanks a lot for your understanding.

Best Regards,

kerry

[SpoonMan]

Don't worry for the delay, I'll wait... I have a lot of tasks waiting in my queue too, so I understand and I can can block current task in the meanwhile and schedule another one.

Let me know when you have some news, thanks in advance!

[kerryzhou]

Hi @SpoonMan ,

  Answer your questions:

1 how this would affect RTOS scheduling?

=>Answer: It won't influence the RTOS schedule, if you design your RTOS properly. Just make sure your API which use erase function can more than 300ms.

2 disabling ALL interrupts during such long operation is good practice?

=>Answer: To this application, which need to do the flash operation in the flash code, disable ALL interrupt just make sure no issue happens. Otherwise, the flash operation may meet issues.

Wish it helps you!

Best Regards,

kerry