Hi NXP experts，
We implemented EEPROM emulation functionality using dflash on the 5606 platform by referencing AN4868 (EEPROM Emulation with Qorivva MPC55xx, MPC56xx, and MPC57xx Microcontrollers). We have now upgraded to the S32K312 platform and noticed that NXP provides an FEE driver based on mcal. However, the FEE driver from NXP requires initialization of the blockID before writing data, making dynamic writing impossible. In contrast, the implementation in AN4868 allows writing data directly with the record number undefined, enabling dynamic data writing. Additionally, I observed that AN4868 uses FLASH reprogramming logic to record states (normally flash does not allow multiple writes unless erased first. However, if the ECC results are the same, and the writing bit is from 1 to 0, data can be rewritten without erasing).
1. Does S32K3's flash support reprogramming without erasing operation?
2. Now, we want to use the implementation code of AN4648 to S32K312. Is this available?
3. If we can migrate code of AN4648 from mpc5606 to S32K312, what should we pay attention to?
4. In spc5606,4 bytes of dflash have one ECC byte,and in s32k312 8 bytes of dflash have one ECC byte.Does this feature have any impact on migrating the logic from the 5606 platform to S32K312 platform?
5. One issue on defining blockID for FEE: For example, if 50 blockIDs are defined but only 10 are frequently written to, will the remaining 40 blockIDs that have not been written to occupy flash space?
6. Our OEM customer does not want to define the ID to be written in advance and prefers to write directly. Can we achieve this functionality by modifying the FEE code?
7. For implementing the logic of AN4648 into S32K312, do you recommend migrating the existing code from the mpc5606 platform or modifying the FEE code?
Hi sir,
many thanks for your reply!!!
(1) (2) (3) (4) The information I provided was incorrect. We just referenced AN4868 to understand the implementation principle of FLASH Emulated EEPROM. In spc5606, we used a driver based on NXP's official offering (link: https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true). After installation, there will be a demo of emulated EEPROM as well as reference manual document. We want to migrate this driver code to S32K312. Is there anything specific to pay attention to when migrating this emulated EEPROM implementation to S32K312?
(5) We know that for data with the same ID, EEE will not repeatedly write to the same flash address to record data. My question is, in the S32K312 FEE driver based on MCAL, if data is only defined but hasn't undergone any write operations, will it actually occupy FLASH space? In the EEE application of mpc5606, our OEM customers might use 1000 IDs to record different faults (there is no need to define all 1000 IDs during initialization, only the fault data corresponding to the ID will be written in real-time when a fault occurs). However, not all 1000 faults will occur simultaneously; typically, a maximum of 10 faults may occur at a time. As the other 990 faults do not actually occupy FLASH space, block swapping will not happen too frequently. If utilizing the MCAL-based FEE driver, even if only 10 faults occur frequently, block swapping would still be frequent if the blockNumber defined during initialization occupies flash space without any write events.
(6) In the case of an autosar-based FEE driver, blockNumber must be defined in advance for writing and reading. However, the EEE driver of mpc5606 allows real-time read and write without the need for prior definition. Nevertheless, OEM customers prefer not to use defined modules, so we are considering migrating the EEE code from mpc5606. With an autosar-based FEE driver, is there a way to write without defining blockNumber?
(7) We strongly recommend OEM customers to use the built-in FEE driver of S32K312. However, we cannot convince customers to add a blockNumber definition module at the application layer. Are there other ways to implement this application scenario based on the FEE driver?
