I'm using an SST26VF (4KB block erase) flash with elm chan's FAT FS. And when I compiled it for my STM32F103 it is using up too much RAM. But Mr. Chan's application notes that memory usage doesn't on the sector size (which I have set as 4096). Why would I be using this much RAM? My program worked perfectly fine with an SD card (FAT sector size is 512 bytes). But now when I reconfigured it for SST26VF its RAM usage is more than what the uC offers.


closed as off-topic by old_timer, Chris Stratton, Voltage Spike, Autistic, brhans Apr 27 '17 at 20:42

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions on the use of electronic devices are off-topic as this site is intended specifically for questions on electronics design." – old_timer, Autistic
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ Seems like not EE question, but rather programming/driver application one. Memory usage is given here elm-chan.org/fsw/ff/en/appnote.html#memory (first column for 32-bit ARM) depending on the mode you choose; one time in the past I tried to contact elm-chan, with no reply from him (and designed my own driver for SD-card using information on his pages and standard definition). \$\endgroup\$ – Anonymous Apr 22 '17 at 9:14
  • \$\begingroup\$ Yes, from the app-note chan provided the FS must not take more than 15Kb. And since the SD worked the RAM usage must be the same for a flash too. The only things that changed were - SD to flash, 512bytes to 4kb. So I'm confused why there was a hike in RAM usage. \$\endgroup\$ – clmno Apr 22 '17 at 12:07
  • \$\begingroup\$ And when you asked Mr. Chan what did he say? \$\endgroup\$ – old_timer Apr 22 '17 at 13:45
  • 1
    \$\begingroup\$ what are your size choices, what did you see when you examined the binary (readelf, objdump, etc) when using 256, 512, 1024, 2048 ..., did something specific change in size, and from there grep the source code for that symbol? \$\endgroup\$ – old_timer Apr 22 '17 at 13:52
  • 2
    \$\begingroup\$ That's still precious short on details to expect help, but in going to 4K with stock settings, you'll replace 1024 bytes of buffers with 8192 bytes of buffers, so if you were around 1000 short of the capacity, that would do it. Unfortunately even the limited buffering option won't fit in that case. You could try Chan's petite fs but it is slow. Better might be to try to reduce memory usage elsewhere in your program. RTOS's can be very wasteful both with excessive housekeeping metadata and in having multiple stacks the sizes of which must be carefully tuned. \$\endgroup\$ – Chris Stratton Apr 24 '17 at 15:49

The size of the minimum erase block dictates the size of the RAM buffer required for RMW (read-modify-write) operations, at least in naive implementations. RMW operations are common in filesystem implementations, used for updating data structures such as directories and allocation tables.

It is possible to work around this by writing the updated data to a previously erased block, but keeping track of such relocations can be very tricky. This is usually done as part of a wear-leveling scheme, which is normally a separate layer of software from the filesystem logic.

  • \$\begingroup\$ Yes, but even in fully buffered mode this adds up to a 8K plus some housekeeping (4K+ in minimal mode, or indeed less with no in place modification). So the poster is either using a very small variant of the STM32F103 or consuming a lot of RAM elsewhere without realizing it. \$\endgroup\$ – Chris Stratton Apr 22 '17 at 17:18
  • \$\begingroup\$ I got it working for AT45DB which has a much smaller erase page size. As for the 4Kb flash, I think it was using too much RAM as Dave said there should be RAM buffers for read, write operations. Thank you @ChrisStratton and Dave. Now any clue how I should go about to implement "wear leveling"? \$\endgroup\$ – clmno Apr 26 '17 at 5:05
  • 1
    \$\begingroup\$ Either switch from FAT to a file system that is designed for flash and already handles this, or drop the filesystem entirely and create your own storage scheme. Simple ideas might be to work through the whole memory before you loop back to the start and start re-using erased regions. While advanced wear leveling may eventually move never-changed data to blocks that have been heavily used, hopefully for your purpose making sure that you distribute changes well would be good. Also try to do append or journal operations rather than modify ones, especially with such a large erase block size. \$\endgroup\$ – Chris Stratton Apr 26 '17 at 14:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.