Can you read from and write to a S32K1 flex memory region simultaneously

[teccl]

If you partition an S32K144 MCU's flex memory region to be partially D-Flash (e.g., 16 kB) and partially E-Flash (e.g., 48 kB), you write some data to the E-Flash partition, and you run a bootloader application from D-Flash, is it possible for the bootloader application to read from and erase/write to E-Flash? (I.e., can an application that is running from the flex memory block simultaneously read/erase/write other sectors in the flex memory block?)

[ck182]

http://ezdsp.com/Web%20Help%20Eng/index.htm?page=S32/S32K1_SDK_Setting_Eng.htm

[Senlent · Accepted solution]

Hi@teccl

No, you cannot simultaneously execute from D-Flash and erase/write E-Flash because they share the same flash controller.

Please take a look at the AN12003.

[teccl]

Hi @Senlent,

Thanks for your reply. Based on the information that you shared, I understand that you cannot erase/write E-Flash in this example. However, it should still be possible to read from E-Flash while running a bootloader from D-Flash, right?

[Senlent]

Hi@teccl

The FTFC operation can be map to SRAM to avoid RWW.

So this is possible to run code in d-flash while read from e-flash, you needs to place FTFC

command into ram.

[teccl]

Hi @Senlent,

Thanks for letting me know. Would you be able to share any NXP documentation that elaborates on how mapping the FTFC operation to SRAM may be done?

[Senlent]

Hi@teccl

1.if you're using bare-metal code, then you can refer to this post:

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K144-Flash-RW-simple/ta-p/1110000

2.If you're using SDK, then you refer to "flash_partitioning_s32k144".

[teccl]

Hi @Senlent,

Thanks again for your help. Just one last quick clarification: if you only want to read from, and not write to/erase, E-Flash while executing code from D-Flash, is it necessary to perform this mapping?

[Senlent]

Hi@teccl

It is still recommended to put FTFC-related operations into SRAM, because the Flash controller requires arbitration access, which may affect performance, but is functionally feasible.

（This is my analysis; I haven't conducted rigorous testing, but placing these operations in SRAM is recommended.）