Yes, as Hui_Ma has said, you've posted in the wrong forum for this chip. Please move it. There's an option under "edit" or something on this page.
You should always ask Google these sort of questions. It finds 882,000 "answers" including this NXP App Note:
https://www.nxp.com/docs/en/application-note/AN3404.pdf
That shows how to "emulate" an EEPROM that can only store EIGHT bytes in far larger Flash blocks. Here's another one:
https://www.silabs.com/documents/public/application-notes/AN568.pdf
That one takes a full copy of the emulated EEPROM and burns it to Flash on every single bit or byte modification to the emulated Flash.
You should also have typed "eeprom emulation" into the Search Bar in these forums. That gives lots of matches, including this one:
LPC8xx EEPROM Emulation
Searching NXP for "eeprom emulation" gets this for the MPC55xx family:
https://www.nxp.com/downloads/en/device-drivers/MPC55XX_EEPROM_EMU_DRIVER.exe
Any "Emulated EEPROM" code assumes you already have working, tested and reliable Flash programming and erasing code. Otherwise (like the above App Notes), they take most of the article showing how to do that on a specific device.
I have a lot of experience with Flash emulation. The code I manage has 1100 lines for the "EE Emulation" and another 1200 lines for the Flash programming and erasing. On Coldfire with external Flash.
It has multiple "image copies" of the emulated EEPROM in each FLASH block, plus "delta lists" of modifications. Sort of like a journaling system.
I would recommend you use an external EEPROM chip. These are cheap and manage themselves quite well. They only take up 2 (I2C) or 4 (SPI) pins on the CPU. Emulation leads to problems of sharing the Flash usage between the EEPROM code and any other use of the Flash. Every now and then a simple "EE Write" has to trigger a Block Erase, and that can take half a second to complete. That either stalls the EE Write or you have to have a threaded OS or task loop doing the work in the "background". Then you have to recover from power off conditions while writing. This gets very complicated if it is to be robust and reliable. The Startup Initialisation code has to scan multiple Flash blocks, looking for the "last good one", handling corruptions and handling the first power-on after production properly. That takes time.
Tom
