Side effects of not properly suspending Flash erase operation?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Side effects of not properly suspending Flash erase operation?

732 Views
carlogravador
Contributor II

Hello!

The MCU we're using supports suspending/resuming of Flash erase operation by setting ERSSUSP bit to request suspending of flash erase

43.4.10.7.1 Suspending an Erase Flash Sector Operation
To suspend an Erase Flash Sector operation set the FCNFG[ERSSUSP] bit when CCIF,
ACCERR, and FPVIOL are clear and the CCOB command field holds the code for the
Erase Flash Sector command. During the Erase Flash Sector operation (see Erase Flash
Sector Command), the flash memory module samples the state of the ERSSUSP bit at
convenient points. If the flash memory module detects that the ERSSUSP bit is set, the
Erase Flash Sector operation is suspended and the flash memory module sets CCIF.
While ERSSUSP is set, all writes to flash registers are ignored except for writes to the
FSTAT and FCNFG registers.
If an Erase Flash Sector operation effectively completes before the flash memory module
detects that a suspend request has been made, the flash memory module clears the
ERSSUSP bit prior to setting CCIF. When an Erase Flash Sector operation has been
successfully suspended, the flash memory module sets CCIF and leaves the ERSSUSP bit
set. While CCIF is set, the ERSSUSP bit can only be cleared to prevent the withdrawal of
a suspend request before the flash memory module has acknowledged it.

What will happen if an interrupt arrives while flash erase operation is executing but ERSSUSP is not set by the ISR code? Will flash erase still resumes after the ISR code execution is completed? The only side effect I read in the reference manual is this:

Aborting the erase leaves the bitcells in an indeterminate,
partially-erased state. Data in this sector is not reliable until a
new erase command fully completes.

We observed that the stack of the task responsible for flash operations overflows when doing consecutive flash operation without suspending/resuming it.

Best regards,
Carlo Gravador

Labels (1)
Tags (2)
0 Kudos
3 Replies

706 Views
PabloAvalos
NXP TechSupport
NXP TechSupport

Hi @carlogravador 

 

I really appreciate your patience and thank you so much for reaching us in our community to get support.

 

Regarding your issue, I am wondering which debugger you are using for that purpose? And which IDE? So I can help you more personalizedly, and try to reproduce your issue on my computer.

 

I will stay tuned to your answer, so if you have more questions or insights, please let me know.

 

Thank you.
Sincerely,
Pablo Avalos.

0 Kudos

691 Views
carlogravador
Contributor II

Hello @PabloAvalos 

Thanks for responding to my question, actually we already found the reason why stack over flow occurs, it happens when a call to a third party library during flash write operation occurs, it can increase the stack size to 1020 bytes (https://github.com/littlefs-project/littlefs), but we still need to investigate if there are side effects of not properly suspending flash erase operation when an interrupt occurs.

Best regards,
Carlo Gravador

0 Kudos

683 Views
PabloAvalos
NXP TechSupport
NXP TechSupport

Hi @carlogravador 

 

Thank you for letting us know with your reply.

 

If you still require further help, please create a new post refering to this thread. We will be more than glad to help you.

 

Best Regards.
Pablo Avalos.

0 Kudos