I am working on a ROM mask chip, so I want to put Filesystem on EEPROM. However, I am not sure where I can start my Filesystem. Can I just start it right at the beginning address of EEPROM?
I am working on a ROM mask chip, so I want to put Filesystem on EEPROM.
That may be the most premature conclusion I've seen here in months. Which, here being what it is, is quite something.
What on earth makes you think that just because you may have to store some data in EEPROM, that would mean you need all the overhead of a file system to do it?
And, though not entirely related, who still uses ROM mask chips to teach embedded computing?
Mask-programmed chips might be nice to use in high-temperature environments where flash memory may not have enough retention time. But they normally also have flash-able "twins" to use for the actual development phase. And if ROM is needed for retention, then the EEPROM part of the design would normally be an issue unless the data can be refreshed using redundant storage and rewrites.
Today, the high volumes of shipped flash devices means that masked chips really should be avoided like the plague. They add lots of costly complications that might end up giving a much higher final cost than standard flash-based microcontrollers.
Thank you very much for your answers!
I agree with what you said, but now the project I am working on is for the Chinese banking area where flash-based chips are not allowed to use. They worry about the security of flash-based chips. This case masked chips are a must.
The reason why I want to design a simple filesystem as I want to store and rewrite some data like account names, balance, and the transition records. Those stuff can't be stored in ROM.
When the economic incentives are large, and the bad guys aren't able to reprogram a flash-based chip, then the bad guys will instead replace the box with an identical-looking box with other electronics.
In the end, physical access to the hardware will always represent a big security issue whatever chip is used.
Anyway - I would normally not use any file system for the type of information you want to store in the EEPROM. It's easier to just preallocate different regions of the EEPROM for different data and then store records of data of different type in the different regions. Preferably complete with good checksum information and redundant storage so the software can handle failed writes (such as after a power loss during save) or broken memory cells. Also with enough spare record space to allow wear leveling by not writing to the same addresses constantly.
So you might have a ring buffer structure for each individual type of information and on each write rotate through the available record positions while using some sequence information to know where the most recent entry is stored.