It seems crazy, but it should work.
You have a 4k block size on the device, and you need to jump to some RAM based code to write each block. It won't be super quick but it will work.
I am mucking about with a FatFS implementation in a 45DBxx (4Mbyte) device, one of the ones with a 512 byte sector size to make things easy, serial over 21mbit/sec SPI2, and it does large file reads at 2Mbytes/sec (about right for the SPI speed being limiting), and writing is 20-30kbytes/sec which is the writing speed limit on this device. I am pretty sure the 32F4 flash writes much faster than the 45DBxx does (a few hundred kbytes writes in a few secs, via the STLINK V3) so the write perf should be fine, and the read perf should be amazing.
I have worked with only STM32F407, but I believe all F4 chips have the same flash memory capabilities & organization. I have some experience on designing my own home-brew pseudo file system which stores (key, data) pairs of arbitrary size, which is inspired from ST's application note on EEPROM emulation on flash.
The properties of the Flash of STM32F4 are as follows:
1. They have [16,16,16,16,64,128,128....,128] kB flash sectors (sometimes called as pages in F0 & F1 docs).
2. Flash controller can write 1, 2 or 4 bytes at the same time. There are supply voltage restrictions. 2 & 4 byte writes must be aligned.
3. An erased/empty sector is full of 0xFF.
4. You can flip bits from 1's to 0's during write operations. To make 0 bits 1 again, sector erase is required.
5. It doesn't cause any error to try 0->1 operation. These are just ignored (this is different from F0 & F1 flash)
6. 1, 2 & 4 byte write operations all take the same time. Can't remember exactly, but it was something like ~15 us.
7. Sector erase time depends on sector size. 128 kB sectors take 1-2 (typical-max) seconds to erase.
8. Unless the device has dual flash banks, flash write & erase operations stops CPU execution until the operation finishes.
I'm not very familiar with FATFS, but I think it's not very suitable for STM32 flash. At least it can't be directly used without wearing the flash very fast. There must be something called "Flash Translation Layer" (FTL). There are also file systems specifically designed for NAND or NOR flashes. SPIFFS is a famous one which is used in ESP8266 and ESP32.
I have verified with a debugger that FatFS does no writes if you access a file. This is common across FAT12 & FAT16 (not FAT32 and others which maintain a "last accessed" stamp).
So the wearing out aspect would depend on how you thrash it when writing. It is certainly possible to do damage with a bit of runaway code, but that's the case for any NV storage apart from a real hard disk.
Another aspect may be if one makes the system accessible over USB, as a logical device. I believe that a 512-byte sector is extra useful for that mode. But that also opens up a way to trash it, with some unknown PC process.
BTW I think your point #8 is not entirely correct. Somebody who seemed to know this told me that the CPU just gets lots of wait states (many many thousands or millions) during the FLASH write, so it doesn't actually stop running totally. I have done designs where the CPU was running code out of EEPROM or FLASH and if you started programming that device, the CPU would get duff opcodes and crash. It seems that ST have implemented this properly, as far as is possible. Code running that slowly may be totally useless (especially for ISRs) but it may be ok in some cases.
From the
Reference Manual of STM32F407 (RM0090):
Any attempt to read the Flash memory on STM32F4xx while it is being written or erased, causes the bus to stall. Read operations are processed correctly once the program operation has completed. This means that code or data fetches cannot be performed while a write/erase operation is ongoing.
On STM32F42xxx and STM32F43xxx devices, two banks are available allowing read operation from one bank while a write/erase operation is performed to the other bank.
It's clear that execution completely stops during flash write/erase operation. Of course, you can move some parts of your program from FLASH to RAM and execute from RAM during a flash write/erase operation. But it would complicate things a lot.
OK; I think we are saying the same thing i.e. the CPU gets wait states during the programming cycle but it doesn't crash which is what normally happens if you are executing out of FLASH or EEPROM and then start a program cycle.
the CPU gets wait states during the programming cycle but it doesn't crash
correct - it just halts the CPU until the flash controller isn't busy