Dear NXP:
My project use s32k312,cache is open.
Regarding the MCAL library fee module, I have the following questions:
In the MCAL library routine provided by NXP, the Fee module parameter Virtual Page Size of the Fee module is 32.
This makes the minimum usage unit in DFLASH 32 bytes,
resulting in a certain amount of DFLASH waste.
I want change this parameter to 16 bytes .
But in RTD_FEE_UM.pdf,
If data cache is enabled, It is recommended to set the FeeVirtualPageSize to 32 bytes.
1. I would like to ask if this description is for 57_xx_s, or for all NXP chips, including the s32k3 series.
2. s32k3 just has 128K DFLASH,when the HSE_B firmware usage feature flag is enabled,just 88K can be used.
When FeeVirtualPageSize is set 32,Block head will use 96byte,66% of space is wasted.
Just 88K * 34% = 29.9K can be used for my project.This is very bad for my project.
In order to use DFLASH reasonably, we need NXP to give recommendations.
Looking forward to your response,
Best Regards,
Luhaiou.
Solved! Go to Solution.
1. The considering of using Code flash and Data Flash is totally up to user, depends on user's application. We could not give the correct suggestion but we only say that Code and Data flash are able to config to use in Fls and Fee configuration.
2. From the view of SW, if 1 sector is damaged, you can use another sector in same block. But it depends on how you define the term "Damaged" in this situation. If it's relating to HW issue then it's hard to say a conclussion
Hi luhaiou,
1. Yes, the description for all platforms.
2. As far as I know, Block header size is design of developer and can't change. This is also noted in UM.
Best regards,
Nhi
@luhaiou I think if you want to use DFlash more reasonably, you can consider to set FeeVirtualPageSize down to 16 or 8 bytes, and disable Data cache
Dear cuongnguyenphu,
Thanks for your reply.
I have one more question I would like to ask you again.
Is the following description also for all platforms?
If it is for all platforms, even if I disable Data cache on the S2K3 chip, I still need to set the virtualpagesize to 32 bytes when using Data FLASH.
If it is not for all platforms,then is the EER bit (used to verify if ECC is present) of S32k3 is affected by 2 DW or 1DW Or...?
Looking forward to your reply, thank you very much.
Hi,
As @Nhi_Nguyen mentioned, the note is for all platform, not only 57XX series
I tested FeeVitualPageSize with 16 bytes aligned with Data flash, and the code still works normally.
Thanks for the reply,
my personal understanding is that when FeeVitualPageSize is set to 16,normal operation is no problem,
only in abnormal cases(reset,power down ...) will increase the probability of ECC errors.
If only code flash segments are configured, the FeeVirtualPageSize can be set to 8 bytes (1 DW). Otherwise, 4 DW (32 bytes) must be used.
This is due to the fact that the EER bit (used to verify if ECC is present) is affected by 4 DW, regardless on the ECC size which is just 1 DW.
Following your response, the above description is for all platforms.
If label 2 has an ECC error, then 1, 3, 4, will all have ECC errors. Because for Data FLASH,EER bit (used to verify if ECC is present) is affected by 4 DW.
If label B has an ECC error, then A, C, D will be OK.
Because for code FLASH, If only code flash segments are configured,
the FeeVirtualPageSize can be set to 8 bytes (1 DW),
EER bit (used to verify if ECC is present) is affected by 1 DW.
Questions
1.Is my understanding correct?
2.If my understanding is correct,I wonder why ECC detection for Data FLASH and code Flash is different
3.If my understanding is correct, for Data Flash, we can't distinguish which DW the ECC error in 4DW comes from.
Then the 32-byte alignment must be set, and the waste of space in the Data Flash is inevitable,
It's a really bad situation for users.
Hi, Let me correct some information.
ECC on S32K3 is handled on a 64-bit boundary (1DW) as per Reference Manual:
The note you hightlighted:
If only code flash segments are configured, the FeeVirtualPageSize can be set to 8 bytes (1 DW). Otherwise, 4 DW (32 bytes) must be used.
This is due to the fact that the EER bit (used to verify if ECC is present) is affected by 4 DW, regardless on the ECC size which is just 1 DW.
is specific for 57XX platform (55nm) to achieve the same robustness as in previous platform.
If you use S32K3, please don't care about this note. In fact ECC on S32K3 is handled by 1DW as RM said. So you can set Fee Virtual page size downto 8 byte
Thanks for the reply,
1. After your patient explanation, I came to the following conclusion:
"Note:" is just for is specific for 57XX platform (55nm)
"Also:" is for all platform
Thank you so much.
2. S32K3xxDS.pdf
Flash memory module life specifications,
I wonder if this specification is for both code Flash and Data Flash.
If it applies to both Code Flash and Data Flash, then Code flash and data flash have the same life cycles, then Can I use part of the code flash sectors as a data storage area, i.e. use code flash as data flash?
If this is possible, the user will have sufficient data storage area.
Whether there are potential risks in doing so?
Looking forward to your reply, thank you very much.
Hi,
Code flash and Data flash are different blocks. See:
As your note, depends on the size of each block, it has different life cycles
Thanks for the reply,
Our project uses s32k312,
P/E cycles is 1000
1.Combined with the FEE cluster mechanism, is it feasible to use the idle sector in Code FLASH as the FeeSectorRef to store data with very little change frequency ( ensure that the number of cluster swaps is less than 1,000 times) during the product life cycle?
2.If one sector is damaged, can other sectors of the same block still be used normally?
1. The considering of using Code flash and Data Flash is totally up to user, depends on user's application. We could not give the correct suggestion but we only say that Code and Data flash are able to config to use in Fls and Fee configuration.
2. From the view of SW, if 1 sector is damaged, you can use another sector in same block. But it depends on how you define the term "Damaged" in this situation. If it's relating to HW issue then it's hard to say a conclussion